JWT Decoder

What Is a JSON Web Token (JWT)?

A JSON Web Token (JWT, pronounced “jot”) is an open standard defined by RFC 7519 for securely transmitting claims between two parties as a compact, URL-safe string. JWTs are the backbone of modern authentication: when you log into an API-backed application, the server issues a JWT that your client sends with every subsequent request to prove identity without hitting a session store.

A JWT consists of three Base64URL-encoded segments separated by dots:

• Header — declares the signing algorithm (alg, typically HS256, RS256, or ES256) and token type (typ, always JWT).
• Payload — contains claims: key-value pairs that carry data about the user and the token itself. Claims can be registered (standardized names like sub, exp, iss), public (custom but collision-resistant), or private (agreed between issuer and consumer).
• Signature — a cryptographic hash of the header and payload, created with a secret (HMAC) or private key (RSA/ECDSA). The signature lets the server verify that the token hasn’t been tampered with.

The resulting string looks like eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U — three dot-separated segments that any Base64 decoder can read, which is exactly what this tool does.

How to Decode a JWT with This Tool

1. Paste the full JWT string into the input field — the token typically starts with eyJ.
2. Click Decode or press Ctrl+Enter. The tool splits the token at the dots, Base64URL-decodes each segment, and parses the header and payload as JSON.
3. Inspect the decoded output: the header shows the algorithm and type, the payload shows all claims with proper indentation.
4. Check token status — if the payload contains exp, iat, or nbf claims, the tool converts the Unix timestamps to human-readable dates and tells you whether the token is currently valid or expired.
5. Copy the decoded result with the Copy button or Ctrl+Shift+C.

The tool also auto-decodes when you paste — if the input looks like a valid JWT (three dot-separated segments starting with ey), decoding happens instantly without clicking a button.

Standard JWT Claims Explained

Understanding the registered claims in a JWT payload is essential for debugging authentication issues:

Beyond these registered claims, tokens typically carry custom claims like role, scope, permissions, or email — whatever the issuer needs the consumer to know without making a database call.

Common JWT Debugging Scenarios

Developers reach for a JWT decoder when something goes wrong in the auth flow. Here are the issues this tool helps diagnose:

“401 Unauthorized” on every request. Decode the token and check exp — the most common cause is an expired access token. If the token expired minutes ago, your refresh-token flow may be broken. If it expired days ago, the user’s session is genuinely stale.

Wrong user or missing permissions. Inspect sub and any role or scope claims. A common bug is issuing a token for user A but populating claims for user B, especially in multi-tenant systems where the wrong tenant context leaks into the token.

“Token not yet valid” errors. Check the nbf (Not Before) claim. If the issuing server’s clock is ahead of the consuming server’s clock, the token’s nbf can be in the consumer’s future, causing rejection. Clock skew between services is a frequent source of intermittent auth failures.

Algorithm confusion. Decode the header and verify the alg field. If your server expects RS256 (asymmetric) but the token says HS256 (symmetric), signature verification will fail — or worse, if the server naively accepts both, it opens the door to the classic algorithm confusion attack where an attacker signs with the public key as an HMAC secret.

Oversized tokens. JWTs go in HTTP headers, and most servers cap headers at 8 KB. If your token carries too many claims (large permission arrays, embedded user profiles), it can silently fail. Decode it and check the payload size — if it’s over 4 KB, consider moving data to a server-side session or a reference token pattern.

JWT vs Other Token Formats

JWTs dominate modern API authentication because they’re stateless — any service with the public key can validate them without calling an auth server. The tradeoff is revocation: you can’t invalidate a JWT before it expires without maintaining a blocklist, which partially defeats the stateless benefit. Short expiration times (5-15 minutes) with refresh tokens are the standard mitigation.

Security Best Practices for JWTs

• Never store secrets in JWT payloads. The payload is Base64-encoded, not encrypted — anyone with the token can read it. This tool proves the point: paste any JWT and read every claim. Don’t put passwords, API keys, or PII in claims.
• Always validate the signature server-side. Decoding a JWT is not the same as verifying it. This browser tool decodes for inspection; your server must cryptographically verify the signature before trusting any claim.
• Use short expiration times. Access tokens should expire in 5-15 minutes. Use refresh tokens (stored securely, not in localStorage) to get new access tokens.
• Pin the algorithm. Configure your server to accept only the algorithm you expect (RS256, ES256). Never let the token’s alg header dictate which algorithm the server uses — that’s the algorithm confusion vulnerability.
• Prefer asymmetric algorithms for distributed systems. RS256 or ES256 let any service validate tokens with the public key, while only the auth server holds the private signing key. HS256 requires sharing the secret with every validating service.