JSON Web Tokens,
opened up

Paste a token to read its header and claims in plain JSON, with issued-at and expiry times resolved against your clock. Decoding happens in your browser, so the token never leaves your machine.

Encoded token

Features

Everything you need to read a token, and nothing that pretends to verify it.

Header and payload as JSON

Both segments are decoded and pretty-printed, with the three parts of the raw token colour-coded so you can see where each came from.

Expiry resolved against your clock

exp, nbf, and iat are converted to readable dates and evaluated, so an expired token is obvious rather than a number you have to convert.

Registered claims explained

The standard claims are listed with what each one means, so you do not need the specification open alongside.

The token never leaves your browser

Decoding happens locally. A real access token pasted into a hosted decoder is a real credential leak; this one makes no requests.

How to decode a JWT

Three steps, all of them local to your browser.

Paste the token

Three base64url segments separated by dots. Surrounding whitespace and a Bearer prefix left behind by a copy are handled.

Read the claims

Header and payload appear as formatted JSON, with registered claims explained in the table below them.

Check the validity window

The banner shows whether the token has expired, how long it has left, and whether it is valid yet.

When you need this

Where reading a token is the fastest way to an answer.

Debugging a 401 response

An API rejecting a request usually comes down to an expired token or a wrong audience. Both are visible in the payload immediately.

Checking what a login returned

See which scopes, roles, and user identifier your auth provider actually issued, rather than what you expected it to.

Confirming token lifetime

Compare iat and exp to see how long a token is valid for, which is the first thing to check when sessions expire too soon.

Reviewing what a token exposes

Anyone holding the token can read every claim in it. Decoding your own is how you find out what you are handing out.

Understanding JSON Web Tokens

What each segment carries, what the registered claims mean, why decoding and verifying are different things, and the two design problems every JWT deployment eventually meets: revocation and storage.

What the three segments contain

A JWT is three base64url strings joined by dots. Splitting on those dots and decoding the first two gives you JSON; the third is the signature and is raw bytes rather than text.

The header names the algorithm and the token type. The payload carries the claims. The signature is computed over the encoded header and payload together, which is why altering either one invalidates it.

header.payload.signature

{"alg":"HS256","typ":"JWT"}
{"sub":"1234567890","name":"Ada","iat":1516239022}
HMACSHA256(base64url(header) + "." + base64url(payload), secret)

Because the signature covers the encoded forms rather than the decoded JSON, re-serialising the payload with different key order would break verification. This is why tokens are passed around as strings and never rebuilt.

The registered claims

Seven claim names are reserved by the specification. None are mandatory, but using them consistently means any library can interpret a token without custom configuration.

iss and aud — Who issued the token and who it is for. A verifier should check both: a valid token issued for a different service should be rejected.
sub — The subject, usually a stable user identifier. It should be unique within the issuer and should not be an email address, since those change.
exp and nbf — The end and start of the validity window, as Unix seconds. Verifiers usually allow a small clock skew in both directions.
iat — When the token was issued. Useful for auditing, and for rejecting tokens older than a policy allows regardless of their expiry.
jti — A unique token identifier, which lets a server track and revoke individual tokens.

Everything else is a custom claim. Namespacing custom claims with a URI is the convention that avoids collisions when tokens pass between systems.

Decoding is not verifying

This is the distinction that causes real vulnerabilities. Decoding reads the claims. Verifying checks the signature against a key, confirms the algorithm is one you accept, and validates the time and audience claims.

Anyone can produce a token with any claims they like. Without verification, "role": "admin" in a payload means nothing at all, because the attacker wrote it.

Two failure modes have caused a long trail of CVEs. The first is accepting the "none" algorithm, where a token with no signature is treated as valid. The second is algorithm confusion, where a server expecting RS256 is handed an HS256 token signed with the public key as the HMAC secret, which the naive verifier accepts.

The defence for both is the same: the server decides which algorithm is acceptable, and the header is never consulted for that decision.

Why revocation is hard

The property that makes JWTs attractive, that a verifier needs no database lookup, is exactly what makes revoking one difficult. A signed token stays valid until it expires, whether or not the user has logged out or been deactivated.

The usual answer is short-lived access tokens paired with a longer-lived refresh token. An access token might last fifteen minutes, so the worst-case window after revocation is small, and the refresh token is checked against a database where it can be invalidated.

A denylist of revoked token identifiers works too, but it reintroduces the lookup the design was avoiding. It is worth it for high-value operations and rarely worth it for everything.

Where to store a token in a browser

This choice is a trade between two attacks. Local storage is readable by any JavaScript on the page, so a single cross-site scripting flaw exposes the token. Cookies can be marked HttpOnly, which puts them out of reach of JavaScript, but are automatically attached to requests and therefore need protection against cross-site request forgery.

The current consensus favours HttpOnly, Secure, SameSite cookies. Cross-site scripting is the more common and more damaging flaw, and SameSite handles most of the forgery risk without extra work.

Whichever you choose, keep the token out of URLs. Query strings end up in server logs, browser history, and referrer headers, and a token in any of those places should be considered leaked.

Common questions

What is a JSON Web Token?

A JWT is a compact, URL-safe way of carrying claims between parties. It has three base64url-encoded parts separated by dots: a header naming the signing algorithm, a payload of claims, and a signature over the first two. It is used most often as an access token, where the claims describe who the bearer is and what they may do.

Does this verify the signature?

No, deliberately. Verifying requires the signing key, which only the issuer and the verifying service hold. A tool that displayed a reassuring green tick without one would be misleading, so this decodes and explains the token without making any claim about its authenticity.

Is it safe to paste a token here?

Decoding happens entirely in your browser and nothing is transmitted, so this page does not see your token. That said, a JWT is a live credential until it expires. Treat pasting one into any online tool the way you would treat pasting a password, and prefer a local tool for production tokens.

Is the payload encrypted?

No. The payload is base64-encoded, which is trivially reversible by anyone holding the token. The signature guarantees that the claims have not been altered, not that they are hidden. Never put anything confidential in a JWT payload.

What does the alg header mean, and what is "none"?

It names the algorithm used to sign the token, such as HS256 for an HMAC with a shared secret or RS256 for an RSA signature. The value "none" means unsigned. A verifier that trusts the header and accepts "none" can be trivially bypassed, which is a well-known vulnerability: the algorithm must be decided by the server, not read from the token.