JWT Decoder
Read the header, payload and claims inside any JSON Web Token.
Decoding happens entirely in your browser — the token is never sent anywhere. This tool reads the token only; it does not verify the signature, so a decoded token is not a trusted one. Avoid pasting production tokens into any online decoder.
Paste in a JSON Web Token to see its header, payload, and claims decoded into readable JSON — useful for debugging authentication issues, inspecting what an API actually put in a token, or checking an expiry claim without writing code.
This only decodes the token's contents; it does not verify the signature, since that requires the issuer's secret or public key, which this tool never has access to.
The three parts of a token
A JWT is three base64url strings joined by dots: header.payload.signature. The header states the signing algorithm, the payload carries the claims, and the signature proves the first two haven't been altered by anyone without the key.
Critically, the payload is encoded, not encrypted. Anyone holding the token can read every claim in it. The signature stops tampering; it does not provide confidentiality.
| Claim | Means | Notes |
|---|---|---|
| iss | Issuer | Who created the token |
| sub | Subject | Usually the user ID |
| aud | Audience | Who the token is intended for |
| exp | Expiry | Unix timestamp; reject after this |
| nbf | Not before | Token is invalid until this time |
| iat | Issued at | When it was created |
| jti | JWT ID | Unique identifier, used for revocation lists |
Security rules that matter
- Never put secrets in the payload. It's readable by anyone who has the token.
- Always verify the signature server-side before trusting any claim, and always check exp.
- Reject the 'none' algorithm explicitly. Accepting it lets an attacker strip the signature and forge any payload — a classic implementation flaw.
- Pin the expected algorithm rather than reading it from the token's own header, or an attacker can downgrade RS256 to HS256 and sign with your public key.
- Keep access tokens short-lived. A JWT can't easily be revoked before it expires, which is the main trade-off against server-side sessions.
- Don't paste production tokens into online tools you don't control. This one decodes locally, but that isn't true of every site.
Frequently asked questions
- Does this verify whether the token's signature is valid?
- No — decoding a JWT only reveals its header and payload, which are just Base64-encoded, not encrypted. Verifying the signature requires the issuer's secret or public key, which isn't something a generic decoder can check.
- Is it safe to paste a JWT here?
- Decoding happens entirely in your browser and nothing is sent to a server, but treat any token as sensitive — avoid pasting tokens for accounts you don't control, since the payload itself is fully readable to anyone with the token.
- What does the 'exp' claim mean?
- exp is the token's expiration time as a Unix timestamp; once the current time passes that value, a properly-validating server should reject the token.
- Can I hide data inside a JWT payload?
- No. The payload is base64url-encoded, which is trivially reversible. If the data must stay private, either keep it server-side or use JWE, which actually encrypts the payload.
- How do I revoke a JWT before it expires?
- You can't, directly — that's the trade-off for stateless verification. The usual workarounds are short expiry times with refresh tokens, or a server-side denylist keyed on the jti claim.
- What's the difference between HS256 and RS256?
- HS256 is symmetric — the same secret signs and verifies, so every verifier can also forge tokens. RS256 is asymmetric: a private key signs and a public key verifies, which is safer when multiple services need to validate tokens.