JSON Formatter
Pretty-print, validate and minify JSON with precise error positions.
Developer & Security
JWT Decoder
Decode header, payload and claims without sending the token anywhere.
What it does. A JWT decoder splits a JSON Web Token into its three Base64url segments and shows the header, payload and signature. This tool decodes locally and checks expiry, issued-at and not-before claims against your clock. It never transmits the token — which matters, because a bearer token is a live credential.
Runs in your browserNothing uploadsNo signupWorks offline
How to use JWT Decoder
- Paste the token. The three segments decode immediately.
- Read the header for the algorithm and the payload for the claims.
- Check the expiry panel for whether the token is currently valid.
Never paste a production token into a website
This is the most important thing on this page, and it applies to every JWT debugger including the well-known ones.
A JWT is not an identifier — it is a bearer credential. Anyone holding it can act as the user it describes, for as long as it is valid, without any password. Pasting one into a site that transmits it hands over a working session.
The standard advice is "only use tokens from a test environment." Better advice is to use a tool that cannot transmit it at all. This decoder is a Base64 split and a JSON parse running in your browser; open the Network tab and paste a token, and you will see no request. If a token has already gone somewhere you are unsure about, revoke the session and rotate the signing key.
What the three segments contain
A JWT is three Base64url strings joined by dots: header.payload.signature.
The header declares the signing algorithm (alg) and token type, plus optionally a key ID (kid) telling the verifier which public key to use.
The payload carries the claims. Seven are registered in RFC 7519 and the rest are application-defined.
The signature is computed over the first two segments with a secret or private key. It is what makes the token trustworthy, and it is the part a decoder cannot check without the key.
| Claim | Name | Meaning |
|---|---|---|
| iss | Issuer | Who created the token |
| sub | Subject | Who the token is about — usually a user ID |
| aud | Audience | Who the token is intended for |
| exp | Expiration | Unix time after which it must be rejected |
| nbf | Not before | Unix time before which it must be rejected |
| iat | Issued at | Unix time it was created |
| jti | JWT ID | Unique identifier, used for revocation lists |
A decoded token is not a verified token
Decoding proves nothing. The payload is Base64, not encryption — anyone can read it, and anyone can write a new one.
Verification means recomputing the signature with the correct key and comparing. Only then do the claims mean anything, and the order matters: verify first, then read the claims. Code that reads sub before checking the signature is trusting attacker-controlled input.
Two verification failures are worth knowing by name. alg: none — a token declaring no algorithm, which some libraries historically accepted as valid. Algorithm confusion — an RS256 token resubmitted as HS256, tricking a server into verifying it with the public key as an HMAC secret. Both are fixed in current libraries; both still appear in code that pins the algorithm from the token rather than from configuration.
Should sensitive data go in a JWT?
No. A signed JWT is readable by anyone who holds it — the browser storing it, any proxy that sees the header, anything that logs a request URL.
Put an opaque user ID and the minimum claims needed for authorization. Keep email addresses, names, roles that reveal organizational structure, and anything regulated out of the payload. If you genuinely need confidentiality, JWE encrypts the payload, but the simpler answer is usually to keep the token thin and look the rest up server-side.
The other reason to keep it thin is size. A JWT travels in an Authorization header on every request, and many servers cap header size at 8 KB. Tokens stuffed with permissions arrays hit that ceiling and produce a 431 that is confusing to debug.
Frequently asked questions
Is it safe to decode a token here?
Yes — the decode happens in your browser and nothing is transmitted. The general risk with JWT debuggers is real, which is why this one is worth verifying in the Network tab.
Can this verify the signature?
Not without the signing key, and the tool deliberately does not ask for one. A signing secret is a higher-value credential than the token itself.
Why is my token rejected when it decodes fine?
Decoding checks nothing. The likely causes are an invalid signature, an expired exp, an aud that does not match the verifier, or clock skew between the issuer and the server.
Is a JWT encrypted?
No. A standard signed JWT is Base64url encoded, which is readable by anyone. JWE is the encrypted variant and is much less common.
What does "alg: none" mean?
An unsigned token. Any verifier that accepts it is critically broken — it means an attacker can mint tokens freely. Current libraries reject it by default.
How long should a token last?
Access tokens: 5 to 60 minutes. Long-lived access tokens cannot be revoked without extra infrastructure, which is what refresh tokens exist to solve.
Can I edit and re-sign a token here?
No, and that is deliberate. Re-signing requires the secret, and no secret should be pasted into a web page.
Guides for JWT Decoder
- Base64, URL Encoding and JWTs7 min read
- MD5 vs SHA-256, and Verifying a Download6 min read