Online JWT decoder

What the decoder displays

A signed compact JWT has three segments separated by dots: header, payload, and signature. The first two contain JSON encoded as Base64URL. The tool decodes and formats those objects, shows the declared algorithm, counts the signature characters, and converts exp, iat, and nbf when they are valid NumericDate values.

Only compact three-segment tokens are supported. An encrypted JWE usually has five and is left out of this version.

Security warning

Decoding is not verification. Anyone can create or alter a plausible header and payload. This tool has no verification key, does not validate the signature, and does not check the issuer, audience, expiration, or any other claim. Describing a date as past or future is only a comparison with the browser clock, not an authentication decision.

Never use this result to grant access or authenticate a user. Real validation needs a maintained library, trusted keys, an explicit algorithm allowlist, and the application’s claim policy.

Structural checks it does perform

• Requires exactly three segments without spaces or Bearer prefix.
• Accepts the Base64URL alphabet without padding and checks its canonical bits.
• Requires valid UTF-8 text in header and payload.
• Requires that both segments contain JSON objects, not lists or single values.
• Preserves numeric literals when rendering JSON, even if they are large.
• Converts numeric exp, iat, and nbf values to UTC and browser-local time when they fit the JavaScript date range, and identifies invalid types.
• Warns about alg: none, missing algorithm or unexpected empty signature.

These checks can detect malformed structure. They cannot prove the token’s origin or integrity.

Common claims

iss identifies the issuer, sub the subject, aud the audience, and exp the expiration time. iat records when the token was issued and nbf the time before which it should not be accepted. These values remain untrusted until the receiving system validates them against its own policy and clock.

exp, iat, and nbf use NumericDate: seconds since the Unix epoch, possibly with a fractional part. The decoder shows the original literal, UTC, the browser’s local time, and whether the instant is past or future. The Unix timestamp converter can inspect other values and units.

The comparison does not apply clock skew, know the server time, or decide whether nbf or exp is acceptable. An application may also enforce a session policy stricter than the date embedded in the token.

You can copy the payload into the JSON formatter or compare standard and URL-safe alphabets in the Base64 converter.

Privacy and secret management

The token does not leave the browser, is not stored, and is not added to the page URL. Still, avoid pasting active tokens on shared computers or in browsers with extensions you do not control. Closing or reloading the tab clears this interface.

Boundaries

The maximum input is 1,000,000 characters. JWE, JSON serialization, certificate handling, JWKS retrieval, and signature verification are not supported. A time claim is converted only when it is a finite JSON number within the browser’s date range; a string such as "1720000000" is reported as the wrong type rather than silently interpreted.

Frequently asked questions

Does a readable payload mean the token is valid?

No. It just means that the segment can be decoded and contains JSON.

Is exp checked?

No. The tool converts exp and compares it with the browser clock, but it does not verify the signature, issuer, audience, server clock, or configured clock skew. It therefore never declares the token valid or expired for a real system.

Why is a five segment token rejected?

It is probably an encrypted JWE. This tool only inspects three-segment compact JWT/JWS values.

Technical references

The compact format and Base64URL are described in RFC 7515; JWT claims, in RFC 7519.