JWT Decoder

Decode and view JSON Web Token Header and Payload data securely.

Read what is inside a JSON Web Token

A JWT looks like a random string with two dots in it, but the first two parts are just Base64URL-encoded JSON. Anyone can read them, which is why sensitive data should never be placed inside a token without encryption. This decoder splits a token, decodes those two parts and shows them as neatly indented JSON so you can see the algorithm, the claims and any expiry field while debugging authentication.

Decoding a token

Paste the full token into the Input Data box, or press Sample to load a well-known example token.
Click Process / Generate.
Two panels appear side by side: HEADER (Algorithm & Type) and PAYLOAD (Data).
Use Copy or Download to keep the output, or Clear to start again.

A line beneath the panels reads Decoded Successfully (Signature not verified), which is an important reminder about what this tool does.

What you will see

The header normally holds the signing algorithm, such as HS256 or RS256, and the token type. The payload holds the claims: subject, issuer, issued-at and expiry timestamps, roles or custom fields. Timestamps such as exp and iat are shown as raw numbers of seconds since 1970, so you will need a converter to read them as dates. The third segment, the signature, is not displayed.

Practical uses

Checking why an API rejects a token by confirming the audience, issuer or role claim.
Inspecting a token returned by a login endpoint during integration work.
Confirming which algorithm a service uses before configuring verification.
Showing colleagues that payload contents are readable by anyone holding the token.

Limitations

The decoder does not check the signature, so a successfully decoded token is not proof that it is genuine or untampered. A forged token decodes just as easily as a real one. It also does not check expiry; use the JWT Validator for that. The token must have exactly three dot-separated parts; anything else produces an error stating the expected structure. Payload text that contains non-Latin characters may appear garbled, because the decoding step reads the bytes as single-byte characters rather than as UTF-8. Encrypted tokens (JWE) have a different structure and cannot be decoded here.

Treat real tokens like passwords: anyone who has one can often use it until it expires. When troubleshooting, prefer short-lived test tokens over production ones. The decoding is performed by JavaScript in your browser page.

Related Tools

Frequently Asked Questions

Does decoding a JWT verify it?

No. The tool only decodes the header and payload and explicitly notes that the signature is not verified. Anyone can create a token that decodes correctly, so decoding is not proof of authenticity.

Why can I read the token contents without a key?

The header and payload of a standard signed JWT are only Base64URL-encoded, not encrypted. The signature protects against tampering, not against reading. That is why secrets should never be stored in a plain JWT payload.

Why do I get an invalid structure error?

A signed JWT must have exactly three parts separated by dots. Extra spaces, a missing segment, a Bearer prefix left in the text, or an encrypted token with five parts will trigger the error or a decoding failure.

Why are exp and iat shown as large numbers?

Those claims are Unix timestamps, meaning seconds since 1 January 1970. The decoder shows the payload exactly as stored, so convert the number to a date separately or use the JWT Validator to see the expiry date.

Is it safe to paste a real token?

The decoding runs in your browser, but a live token can grant access until it expires. It is safer to use a test or expired token when troubleshooting, and to revoke or rotate any token you have shared by mistake.