About JWT Decoder
JWT Decoder splits any JSON Web Token into its three parts — header, payload, and signature — and shows you what's inside. Paste a token and you'll instantly see the algorithm, claims, issuer, audience, and expiry time in a colour-coded, human-readable view. Useful for debugging auth flows, inspecting tokens from your API, or just learning what JWTs actually contain. Everything happens in your browser; the token is never logged, sent, or stored anywhere, which matters because real JWTs leak account access.
- No uploads
- Browser-only
- Works offline
- 100% free
How it works
- 1
Paste the token
Drop a JWT into the input — the classic three-segment base64url string separated by dots. The decoder accepts tokens with or without a leading 'Bearer '.
- 2
Read the decoded sections
Header (alg + typ) and payload (claims like sub, iss, aud, iat, exp) are rendered as syntax-highlighted JSON. Standard timestamp claims are converted to readable dates.
- 3
Check expiry and copy
An expiry badge tells you whether the token is still valid. Use the copy buttons to grab any decoded section as JSON for a bug report or test fixture.
What a JWT actually is (and isn't)
A JSON Web Token (RFC 7519) is three base64url segments joined by dots: a header saying how it's signed, a payload of claims, and a signature. This decoder splits and renders the first two. The single most important thing to understand: the payload is encoded, not encrypted. base64url is reversible by anyone — which is exactly why this tool can read your token without a key, and exactly why you must never put a secret (password, API key, card number) in a JWT payload. Anyone holding the token can read it.
The signature is what makes a JWT trustworthy: it proves the token was issued by someone holding the signing key and hasn't been altered. Decoding shows you the claims; it does not and cannot tell you the signature is valid — that check belongs on your server.
The claims worth knowing by name
| Claim | Means | Why it matters |
|---|---|---|
| iss | Issuer | Who minted the token — pin it to your auth server |
| sub | Subject | The user or entity the token is about |
| aud | Audience | Who the token is for — reject tokens not addressed to your API |
| exp | Expiry | Unix time after which the token is invalid — always enforce it |
| iat | Issued at | When it was minted — useful for max-age policies |
| nbf | Not before | Token isn't valid until this time |
| jti | JWT ID | Unique id — enables revocation and replay lists |
iss, sub, aud, exp, nbf, iat and jti are the registered claims from RFC 7519; everything else is application-defined.
Security gotchas that bite real apps
- alg: none — the spec allows an 'unsecured' JWT with no signature. A verifier that trusts the header's alg can be tricked into accepting a forged token. Real libraries reject 'none' by default; never re-enable it.
- RS256 vs HS256 confusion — feed an RSA public key to an HMAC verifier and an attacker can sign tokens with that public key. Pin the expected algorithm; don't let the token's header choose it.
- Expired but accepted — a decoder shows exp, but only your verifier enforces it. Check exp (and the signature) server-side on every request.
- Tokens in URLs and logs — a JWT in a query string ends up in server logs, browser history and Referer headers. Send them in the Authorization header, not the URL.
Why this tool decodes but never verifies
Verifying a signature requires the issuer's secret (HS256) or public key (RS256). Pasting a signing secret into any third-party website — even one that runs entirely client-side — is a habit worth never forming, so this tool deliberately stops at decoding. Do verification where the key already lives: inside your backend, with a maintained library that checks the signature, the algorithm, exp and aud together. Treat a real token like a password while you debug — decode an expired copy, or corrupt the signature segment first, so a screenshot or shoulder-surfer can't reuse it. To inspect the raw segments by hand, Base64 Decode each part; to pretty-print the decoded claims, use the JSON formatter.
Related guides
All guidesDeveloper
A daily developer toolkit that never opens a tab to elsewhere.com
JSON, Base64, regex, hash, diff, JWT — the everyday utilities developers reach for, all in one place, all local.
6 min read
Developer
JWT explained — anatomy, security pitfalls, and what to check in a token
Three base64url-encoded parts joined by dots. Most of the bugs aren't in the format — they're in how people verify it.
11 min read
Developer
Regular expressions — a practical primer from beginner to advanced
A small DSL for matching shapes in text. Powerful, occasionally treacherous, and well worth the afternoon it takes to internalise.
12 min read
Concepts
AES vs RSA: symmetric and asymmetric encryption explained
Two encryption schemes, two different jobs. Why almost everything secure uses both — and which one is doing what when you send a file.
8 min read
Frequently asked questions about JWT Decoder
Does this tool verify the signature?
No. This is a decoder, not a verifier — it shows you what's inside the token but does not check the signature against a secret or public key. Signature verification needs the issuer's key, which you should never paste into a third-party site. For real verification, run the check inside your own backend with a trusted JWT library.
Can I decode a JWE (encrypted JWT)?
No. The tool decodes JWS tokens (the common signed format). JWE tokens use five segments instead of three and require a decryption key, so they show up as 'malformed'. JWS is what nearly every OAuth and OIDC flow issues.
Is it safe to paste a real production token here?
Yes — the token is parsed entirely in your tab and never leaves it. That said, treat any JWT like a password: a valid, unexpired token grants account access. If you're worried, decode an expired copy or change the signature characters to something invalid first.
Privacy, offline use, browser support, and pricing questions are answered on the site-wide FAQ.