JWT decoder
Decode a JSON Web Token to read its header and claims. The token never leaves your browser.
Runs 100% in your browserHow to decode a JWT
- Paste your token. Paste the full JWT (header.payload.signature) into the box.
- Read the claims. The header and payload are decoded and pretty-printed; standard time claims are shown as dates.
- Check expiry. The decoder flags whether the exp claim is still in the future, so you can tell at a glance if the token is live or stale.
The three parts of a JWT
A JSON Web Token is three Base64URL-encoded segments joined by dots:
header.payload.signature. The header is a small JSON object naming the
signing algorithm (alg, e.g. HS256) and token type (typ: JWT). The
payload is a JSON object of claims — statements about the user or session. The
signature is computed over the first two parts using a key, and it is what makes the
token trustworthy: change a single character of the header or payload and the signature no longer
matches. This decoder splits the token, Base64URL-decodes the first two parts, and pretty-prints the JSON
so you can read exactly what a token asserts.
Registered claims worth knowing
The JWT standard (RFC 7519) reserves a handful of short claim names with defined meanings:
iss (issuer), sub (subject — usually the user id), aud (audience —
who the token is for), exp (expiry), nbf (not-before), iat
(issued-at) and jti (a unique token id, useful for revocation lists). Everything else is a
custom claim you define — roles, tenant, scopes. Keep the payload small: it travels on every request, and
every byte is overhead. This page surfaces the time claims as dates and tells you whether the token is
still within its exp.
Signed, not encrypted — decode is not verify
The single most important thing to understand about a JWT is that the standard token is
signed, not encrypted. Base64URL is an encoding, so the payload is fully readable by
anyone holding the token — which is exactly why this tool can decode it without any key, and exactly why
you must never put a password, card number or secret in it. The signature proves the token was issued by
someone holding the key; it does not hide the contents. That distinction drives the cardinal
rule: always verify on the server, never trust a decoded payload on the client. Pin the
expected algorithm (reject the alg: none trick), check exp, nbf
and aud, and only then act on the claims.
Why tokens are decoded locally here
A JWT is a live credential — whoever has it can act as the user until it expires. So a decoder must never transmit it. This page does everything in your browser: it splits the token, fixes the Base64URL padding, decodes the bytes as UTF-8 and parses the JSON, all locally, with nothing sent anywhere. The same Base64URL scheme is explained by the Base64 tool, and if you want to reformat a decoded payload further, the JSON formatter handles indentation and key sorting. Want to do it in code? Our guide to decoding a JWT in JavaScript shows the few lines involved — and why decoding a token is not the same as verifying it.
Frequently asked questions
- A JSON Web Token is a compact, signed token with three Base64URL parts separated by dots: a header, a payload of claims, and a signature. It is widely used for authentication and stateless sessions.
- No. This tool decodes the header and payload so you can read the claims. It does not verify the signature, which would require the secret or public key. Never trust a token's contents without verifying it on your server.
- Yes — decoding happens entirely in your browser and the token is never sent anywhere. Still, treat real tokens as secrets and avoid pasting production credentials into any online tool you don't control.
exp(expiration),iat(issued-at) andnbf(not-before) are Unix timestamps in seconds. A token is only valid between nbf and exp. This decoder shows iat and exp as human-readable UTC dates and flags a token whose exp is in the past as expired.- Yes — and that is the point of this tool. The header and payload are only Base64URL-encoded, not encrypted, so anyone can read them. What you cannot do without the key is forge a valid one or confirm a token is authentic — that requires verifying the signature against the secret (HS256) or public key (RS256/ES256).
- Because the payload is readable by anyone who holds the token — your browser, a proxy log, the client app. A JWT proves a claim was signed by your server; it does not hide the claim. Put an opaque user id and the minimum needed for authorization, never passwords, card numbers or API keys.
- Early JWT libraries trusted the header's alg field, so an attacker could change it to "none", strip the signature, and have the token accepted unverified. Always pin the expected algorithm server-side and reject "none". This is the headline reason you must verify, not just decode, on the server.