How to use this tool
- Paste a three-part compact token with segments separated by dots. Omit any Bearer prefix.
- Select Decode header and payload. Read the output as unverified data supplied by the token.
- Use your application’s trusted JWT library and configured keys for actual verification; do not authorize access from this decoded output.
Understanding the output
The output shows the decoded header and payload, together with an explicit statement that signature verification was not performed. Claims such as sub, exp, iss, or aud are displayed as data without deciding whether they are acceptable. Even a plausible algorithm name or future expiry timestamp does not establish that the token came from a trusted issuer.
To inspect a NumericDate claim as a UTC date, use the Unix Timestamp Converter with seconds selected; date conversion does not verify the token.
Inspecting a demonstration subject
The default demonstration decodes to header {"alg":"HS256","typ":"JWT"} and payload {"sub":"demo","iat":1704067200}. Its placeholder signature AA is not a verified signature. The output reports two payload claims and does not label the token valid.
Readable claims do not prove trust
Base64url encoding lets a header and payload travel as URL-compatible text. It does not hide their contents, and anyone can construct a token-shaped string with convincing claims. A signature verification step must use the application’s trusted key material and allowed algorithms, followed by the relevant issuer, audience, and time checks. This decoder deliberately performs none of those trust decisions.
The header’s alg field is part of the untrusted input. Displaying its value is useful when debugging an integration, but an application must not accept arbitrary verification behavior simply because a token asks for it.
Inspect time claims in their own units
JWT NumericDate claims commonly express seconds since the Unix epoch. A value such as 1704067200 is therefore different from the millisecond timestamps used by some programming interfaces. This tool leaves those numbers unchanged so that their original representation remains visible. If you convert a claim to a date, keep its meaning separate from whether the application should accept the token.
Method and supported input
The token is split into three segments. Header and payload are decoded from unpadded Base64url through a strict UTF-8 decoder and parsed as JSON objects. The signature segment is checked only for basic encoding shape and is never cryptographically verified.
- The input is a three-part compact JWT containing JSON header and payload objects.
Limitations
- Tokens are limited to 16,000 characters; each decoded object may contain at most 2,000 values and 32 nesting levels. Encrypted five-part tokens, detached payloads, and non-JSON payloads are unsupported.
- Duplicate JSON keys and exact large-number precision are not preserved. No signature, expiry, issuer, audience, or revocation verification is performed.
Common questions
Does successful decoding mean the token is valid?
No. It means the supported segments could be decoded into JSON objects. Authenticity and application acceptance require separate verification.
Can this decode an encrypted JWT?
No. Five-part encrypted compact tokens need the appropriate decryption context and are outside this tool’s scope.
Why are exp and iat still numbers?
Claims are displayed without reinterpretation. Use seconds when converting NumericDate values, and verify claim handling in the receiving application.