JWT Decoder (Decode JWT Tokens)
Paste any JWT to see its header, payload, and signature — with a claims table, expiry badges, and unsigned-token warnings, all in your browser.
Decoding happens entirely in your browser — the token never leaves your device.
What this tool is best for
- Debugging access tokens and ID tokens during API development.
- Checking expiry (exp), issued-at (iat), and not-before (nbf) claims at a glance.
- Inspecting what data your auth server puts inside the payload — safely, offline.
JWT decoder online free (decode any JWT in your browser)
A JSON Web Token looks like gibberish — three long base64url strings separated by dots — but everything inside it is readable. The header and payload are just base64url-encoded JSON; only the signature is cryptographic. That means any JWT can be decoded without a secret key, which is exactly what this tool does: paste a token and instantly see the algorithm, every claim, and whether the token is still valid. No signup, no server round-trip, no trace of your token left behind.
Decoding is the easy part of working with JWTs — understanding what you are looking at is harder. This page walks through the anatomy of a token, the registered claims that matter (especially the time-based ones: exp, iat, nbf), and the safety rules that keep you out of trouble when tokens cross your screen.
This decoder vs jwt.io
| Property | This decoder | jwt.io |
|---|---|---|
| Token leaves your browser | Never — decoding is 100% local | Never (client-side too) |
| Expiry status badges | Yes — exp, nbf and iat shown as dates with valid/expired badges | No — raw timestamps only |
| Registered claims table | Yes — iss, sub, aud, exp, nbf, iat, jti explained | No — raw JSON only |
| Unsigned-token warning | Yes — prominent alert for alg: none | Yes |
| Click-to-highlight segments | Yes — click header, payload or signature to highlight it | No |
Anatomy of a JWT
Every JWT has the same shape: header.payload.signature. The header is a small JSON object naming the signing algorithm (alg, usually HS256 or RS256) and the token type (typ: JWT). The payload carries the claims — the actual data, like the user ID (sub), the issuer (iss), and the expiry (exp). The signature is computed over the first two parts with the server’s secret key; it is what stops anyone from editing the payload and reusing the token.
The critical insight: the payload is signed, not encrypted. Base64url is an encoding, not encryption — anyone who intercepts the token can decode and read every claim. Never put passwords, full personal data, or anything sensitive in a JWT payload. If the payload must stay secret, use JWE (encrypted JWT) instead.
The time claims: exp, iat, nbf
Three registered claims control a token’s lifetime, all as Unix timestamps in seconds. exp (expiration time) is the deadline — after it passes, the token must be rejected. iat (issued at) records when the token was minted, useful for auditing. nbf (not before) sets an activation time for tokens that should not be valid yet. This decoder converts all three into readable dates and shows at a glance whether the token is valid, expired, or not yet active.
Short lifetimes are a security feature, not an annoyance: access tokens commonly live 15 minutes to a few hours, so a leaked token quickly becomes worthless. Long-lived refresh tokens are stored separately and rotated. If your debugger keeps showing expired tokens, the fix is a refresh flow — not a longer expiry.
Safety rules for real tokens
Treat every JWT like a password while it is valid: whoever holds it is the user, as far as your API is concerned. Do not log full tokens, do not commit them to git, and do not paste production tokens into chat windows or issue trackers. When debugging, prefer tokens from a local or staging environment. And if you ever see “alg”: “none” in the header, stop — that token has no signature at all and must never be accepted by a real server.
Related developer tools
Pair this with ToolsOfWeb's JSON Formatter to pretty-print the decoded payloads you copy out, the Base64 Converter to understand the encoding underneath JWT segments, or the Regex Tester to validate token formats in your codebase.
FAQs
What is a JWT?+
A JSON Web Token (JWT, RFC 7519) is a compact, URL-safe token with three dot-separated parts: a header, a payload of claims, and a signature. Servers issue them after login so APIs can verify who you are without a database lookup on every request.
Is it safe to paste tokens into this decoder?+
Yes — decoding runs entirely in your browser and the token is never uploaded anywhere. Still, avoid pasting real production secrets into any website, and remember a JWT payload is only base64-encoded, not encrypted: anyone holding the token can read it.
What are the header, payload, and signature?+
The header names the signing algorithm (e.g. HS256) and token type. The payload carries claims — statements like who the token is for (sub) and when it expires (exp). The signature is created with the server’s secret key and proves the token wasn’t tampered with.
Why does the decoder say my token is expired?+
The payload’s "exp" (expiration time) claim is a Unix timestamp in the past. Tokens are short-lived by design — typically minutes to hours — so an expired token just means you need to log in again or refresh it.
What does "alg: none" mean?+
It means the token is unsigned: there is no signature to verify, so anyone can forge it. Unsigned tokens should never be trusted for authentication — treat them as a red flag, not a valid credential.
More free tools
Want guides and tips? Visit the ToolsOfWeb blog or go back to the homepage.