JWT Decoder — Free Online Token Inspector

A JSON Web Token (JWT) is the small, signed credential that powers login sessions and API authentication across much of the modern web. It looks like three random-looking strings separated by dots — header.payload.signature — and each of the first two parts is simply JSON encoded with base64url. Decoding a JWT means reversing that encoding so you can read what is inside.

Developers reach for a JWT decoder when an API rejects a request with a vague 401 error, when they need to confirm which user or permissions a token carries, or when they are building the login flow itself and want to see exactly what their authentication server is issuing. Support engineers use it to inspect tokens customers paste into tickets, and students use it to learn how token-based auth actually works.

This free JWT decoder runs entirely in your browser. Paste a token and the header and payload appear as readable, pretty-printed JSON in milliseconds. Nothing is uploaded to any server, which matters because tokens often grant access to real accounts — you should never paste a live production token into a tool you do not trust.

How to use the JWT decoder

1. Paste your token into the input box — the full xxxxx.yyyyy.zzzzz string, exactly as your app sends it.
2. Check the structure. The tool confirms the token has all three parts; if not, it tells you plainly what is wrong instead of failing silently.
3. Read the decoded header. You will see the signing algorithm (alg, usually HS256 or RS256) and the token type.
4. Read the decoded payload. This is where the claims live: user id (sub), expiry (exp), issued-at time (iat), and any custom data your API added.
5. Copy what you need. Use the copy button to grab the payload JSON for your notes, a bug report, or a config file.

Key features & benefits

• 100% client-side decoding. Your token never leaves your device — there is no server log that could leak a credential.
• Pretty-printed JSON. Header and payload are formatted with indentation, so nested claims are easy to scan.
• Algorithm at a glance. The alg value is surfaced immediately, which is the first thing to check when signature verification fails.
• Honest signature status. The tool reports whether a signature is present and states clearly that it is not verified — decoding is not the same as trusting.
• Clear errors for bad tokens. Truncated tokens, missing parts, and non-JSON payloads each get a specific, human-readable message.
• One-click sample. New to JWTs? Load the built-in sample token to see what a decoded token looks like before pasting your own.

Understanding JWT structure

Every JWT has the same three-part anatomy. Knowing what each part does makes debugging far easier, because most token problems live in exactly one of them.

Header

The header is a tiny JSON object, usually just {"alg":"HS256","typ":"JWT"}. It declares how the token was signed. If your server expects RS256 but the token says HS256 — or none — you have found your bug, and it is a serious security matter, not a typo.

Payload (claims)

The payload carries the claims: statements about the user and the token itself. Standard claims include sub (subject, often the user id), exp (expiry as a Unix timestamp — convertible with our Unix timestamp converter), iat (issued at), and aud/iss (audience and issuer). Anything else is custom data your application added.

Signature

The signature is created by signing the first two parts with a secret key. It is what stops attackers from editing the payload. Decoding does not check it — that requires the secret — so a decoded token tells you what the token claims, never whether the claim is legitimate.

Frequently asked questions

How It Works: Under the Hood

A JWT (JSON Web Token) is three Base64URL-encoded segments joined by dots: header.payload.signature. The header names the signing algorithm (typically HS256 or RS256) and token type. The payload holds claims — JSON key-value pairs like sub (subject/user ID), exp (expiry timestamp), iat (issued at), iss (issuer), and any custom claims the application added.

The signature is what makes JWTs trustworthy: the issuer signs header.payload with a secret (HMAC) or private key (RSA/ECDSA). Anyone can decode a JWT — the payload is merely encoded, not encrypted — but only the key holder can produce a valid signature. A decoder like this one shows you the contents; it does not verify the signature (that requires the secret/key, which you should never paste into a browser tool).

Critical detail: Base64URL differs from standard Base64 — it uses – and _ instead of + and /, and typically omits padding. The exp claim is a Unix timestamp in seconds — a classic bug source when code compares it against millisecond timestamps.

Real-World Use Cases

• Debugging “401 Unauthorized”: a front-end developer pastes the failing request’s token and immediately sees exp is in the past — the bug is token refresh logic, not the API.
• Verifying role claims: a QA engineer decodes a test user’s token to confirm the roles or scope claims actually contain “admin” before testing permission-gated endpoints.
• Checking token lifetimes: a mobile developer inspects iat vs exp to confirm the backend issues the intended 15-minute access tokens and 7-day refresh tokens — not the reverse.
• Auditing third-party integrations: a security reviewer decodes a vendor’s JWT to see exactly what personal data (email, name, user ID) is embedded in tokens flowing through the integration.
• Reproducing auth bugs: support pastes a customer’s (expired, safe-to-share) token to see which iss and aud values it carries, identifying a misconfigured environment.

Advanced Tips

• Convert exp to a human date instantly: paste the exp number into the Unix timestamp converter to see the actual expiry date — “is this token valid for an hour or a year?” becomes obvious.
• Look for claim bloat: if the payload contains entire user profiles, permissions matrices, or nested objects, the token is oversized — every request carries that weight. Flag it to the backend team.
• Distinguish decode from verify: this tool answers “what does the token say?” — never “is it authentic?” A forged token decodes just as prettily. Signature verification happens server-side with the real key.
• Check the alg header for downgrade attacks: if the header says alg: none, the token is unsigned — some infamous vulnerabilities came from servers accepting these. The header is the first thing to inspect.

Common Mistakes to Avoid

• Pasting live production tokens: JWT payloads often contain emails, user IDs, and internal claims. Decoding a live token in any browser tool exposes it — use expired tokens or test-environment tokens for debugging.
• Assuming the payload is encrypted: it isn’t. Never put passwords, API secrets, or sensitive PII in JWT claims — anyone who intercepts the token reads them with zero effort.
• Trusting exp alone for security: expiry limits damage, but a stolen token is fully usable until it expires. Short expirations + refresh-token rotation is the real defense, not the timestamp itself.
• Mixing up seconds and milliseconds: exp is seconds since epoch; JavaScript’s Date.now() is milliseconds. Comparing them directly makes every token look expired (or valid for 50,000 years).

Debugging the Dreaded 401 With a Token Decode

A 401 Unauthorized rarely tells you why. Paste the token your app sent and read the payload: an expired exp claim is the most common culprit, followed by a wrong audience (aud) or a missing scope. If the structure check fails, the token was truncated in transit — a classic copy-paste casualty. Decode before you blame the backend; half of all auth bugs are visible right here in the claims. Tokens are just base64url-encoded JSON — the Base64 encoder decoder shows the raw encoding underneath.

Production Tokens: What Never to Paste Anywhere

This decoder runs entirely in your browser — nothing is uploaded, which is exactly what you want for tokens that grant real access. Still, treat every production token like a password: decode it, fix the issue, and move on. Never paste live tokens into chatbots, forums, screenshots, or server-side “free” decoders you don’t trust. If a production token was ever exposed, revoke or rotate it rather than hoping nobody noticed. Validate the surrounding JSON structure with the JSON formatter.