A JSON Web Token packs three pieces of information into a compact, dot-separated string: a header (which algorithm signed it), a payload (the actual claims about who or what it represents), and a signature (proof that the issuer made it). This tool decodes the first two and surfaces the standard claims with human-readable timestamps.
How a JWT is built
A JWT is three base64url-encoded segments separated by dots:
HEADER.PAYLOAD.SIGNATUREThe header is a small JSON object describing how the token was signed: {"alg":"HS256","typ":"JWT"} is the most common shape.
The payload is a JSON object containing claims. Some claim names are standardised by RFC 7519 (the JWT spec): iss, sub, aud, exp, nbf, iat, jti. Anything else is application-specific.
The signature is computed over the header and payload using the algorithm in alg and a key only the issuer holds. The signature lets a recipient verify the token wasn’t tampered with — but verification requires the key, which is why this tool doesn’t do it.
Example: a typical session token
A token like:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiJ1c2VyLTEyMyIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTcwMDAwMDAwMCwiZXhwIjoxNzAwMDAzNjAwfQ.
fake-signaturedecodes to:
- Header:
{"alg":"HS256","typ":"JWT"} - Payload:
{"sub":"user-123","name":"Alice","iat":1700000000,"exp":1700003600}
The iat (issued at) translates to 2023-11-14T22:13:20Z, and exp to 2023-11-14T23:13:20Z — a one-hour token. The badge tells you whether exp is in the past relative to your local clock.
When to use this
- Debugging auth flows — see what claims your identity provider is actually putting in the token, vs what your server expects.
- Inspecting third-party tokens —
id_tokenfrom OIDC, access tokens from SaaS APIs. - Quick sanity checks — confirm a token isn’t expired, that
audmatches your service, thatissis the right issuer. - Educational use — see how the format is built without writing code.
Common mistakes
Treating decode as verification. Decoding a JWT proves nothing about authenticity — anyone can build a token with any claims. A real backend must verify the signature using the issuer’s key before trusting any claim inside.
Pasting tokens into untrusted tools. A JWT often carries personally identifying claims (email, user ID, org membership). This tool runs entirely in your browser, but many online JWT debuggers send the token to a server. Check the network tab before pasting anything sensitive into any web tool.
Confusing JWS and JWE. Both are “JWT” but only JWS (3 segments, signed) is decodable without a key. JWE (5 segments, encrypted) needs the recipient’s private key to read the payload.
Reading exp as milliseconds. Standard claims (exp, iat, nbf) are seconds since epoch, not milliseconds. A timestamp like 1700000000 is November 2023, not January 1970. The tool handles the seconds-to-milliseconds conversion when formatting.
What this tool does not do
It doesn’t verify signatures. Use a server-side library with the appropriate key.
It doesn’t decode JWE (encrypted tokens, 5 segments). Decryption requires the recipient’s private key.
It doesn’t edit or re-sign tokens. A new token must come from the issuer; a tampered token will fail signature verification.
It doesn’t store the token between sessions. Refreshing the page loses the input — by design, so a clipboard token doesn’t accidentally hang around in browser state.
For just the base64url header / payload slices without the JWT semantics, the Base64 encoder / decoder gives raw round-tripping.