JWT Decoder
A JWT decoder reads a JSON Web Token — the compact string your app passes around after login — and shows you what's inside: the header, the payload claims, and whether the token has expired. Paste a token below and it's decoded instantly, 100% in your browser: nothing is uploaded, which matters when tokens carry user IDs, emails, or permissions. You can also verify an HS256 signature if you hold the secret.
Header
Payload
Timestamps
Signature
Shown as raw base64url — decoding does not verify it.
Verify HS256 signature (optional)
100% client-side — your token never leaves this browser.
What the three parts are
A JWT is three base64url-encoded segments joined by dots. Each has a distinct job:
| Part | Contains | Example |
|---|---|---|
| Header | The signing algorithm (alg) and token type (typ) | {"alg":"HS256","typ":"JWT"} |
| Payload | The claims — user ID, expiry, issuer, and any custom data | {"sub":"1234567890","exp":1893456000} |
| Signature | HMAC or RSA/ECDSA signature over header + payload | Raw base64url — not human-readable |
The standard registered claims you'll meet most often: iss (issuer), sub (subject — usually the user ID), aud (audience), exp (expiry), iat (issued at), nbf (not valid before), and jti (unique token ID).
Common use cases
- Debugging OAuth logins — check which claims your identity provider actually put in the token.
- Checking expiry — see whether a failing request is just an expired token before digging deeper.
- Identifying the algorithm — read
alg(andkid) from the header to know which key or method verifies the token. - Verifying issuer and audience — confirm
issandaudmatch what your OpenID Connect client expects. - Reading custom claims — inspect roles, permissions, or tenant IDs your backend embedded in the payload.
How to use it
- Paste the JWT into the box (or try the sample token) — decoding is instant.
- Read the pretty-printed header and payload, and check the Valid/Expired badge.
- To verify an HS256 signature, enter the secret and click Verify signature.
- Copy the JSON you need with the copy buttons.
Decoding is not verification
This is the single most misunderstood thing about JWTs: anyone can decode a token, with no key. The payload is only encoded, not encrypted — treat every claim in it as readable by whoever holds the token. Verification is the separate step where the signature is recomputed with the secret (or public key) to prove the token wasn't forged or altered. A beautifully decoded payload tells you nothing about whether the token is genuine — only a successful signature check does.
Reading exp, iat, and nbf
Time claims are Unix timestamps in seconds. exp is the hard deadline — after it, the token must be rejected. iat records when it was issued, and nbf marks the moment before which it isn't valid yet (useful for tokens minted slightly ahead of use). The decoder converts all three to UTC dates with relative times ("in 3 days", "2 hours ago"), so you don't have to convert timestamps by hand.
Getting the token out of your app
Most tokens live in browser storage or request headers. The quickest way to grab one:
- Open DevTools (F12) and go to the Network tab.
- Trigger the request your app makes (reload the page or click the action).
- Click the request, open Headers, and find the
Authorization: Bearer <token>header. - Copy the token part (after "Bearer ") and paste it into the decoder above.
Frequently asked questions
- Does this verify the token's signature?
- Decoding alone never verifies anything — it just reads the token. This tool can optionally verify an HS256 signature: enter the secret and it recomputes the HMAC with WebCrypto, entirely in your browser. Tokens signed with RS256, ES256, or other algorithms can be decoded here but not verified.
- Can I decode a JWT without the signing key?
- Yes. The header and payload are only base64url-encoded, not encrypted, so anyone holding the token can read them — no key needed. The signing key is only required to verify that the token is authentic and untampered.
- Is my token uploaded anywhere?
- No. Decoding and HS256 verification both run entirely in your browser using the WebCrypto API. Nothing is sent to any server — which also means you can safely inspect tokens containing non-public claims.
- What does the exp claim mean?
- exp is the expiry timestamp in Unix seconds. Once the current time passes it, servers should reject the token. The decoder converts exp (along with iat and nbf) to a readable UTC date and shows a Valid/Expired badge so you can see at a glance whether a token is still usable.
- What's the difference between an access token and an ID token?
- An access token authorizes actions — it tells an API what the bearer is allowed to do. An ID token (OpenID Connect) authenticates identity — it tells the client who the user is, with claims like sub, name, and email. Both are usually JWTs, which is why the same decoder reads either.
- Why does my token show as invalid?
- First check the structure: a JWT must be exactly three base64url parts separated by dots, and each of the first two must decode to valid JSON. If decoding works but signature verification fails, either the secret is wrong or the token was modified after signing — both produce the same "invalid" result.
- Can I decode an expired token?
- Yes — expiry doesn't affect decoding at all. The payload reads exactly the same; only the badge changes to "Expired". That's useful for debugging: you can still inspect the claims of a token your server just rejected.