What is JWT Decoder?
A JWT (JSON Web Token) is the standard way modern web APIs represent authentication and authorization claims. It's a compact, self-contained token made of three parts — a header describing the signing algorithm, a payload carrying the actual claims (like user ID, roles, and expiration), and a signature that lets the receiving server verify the token hasn't been tampered with.
This decoder reads the header and payload instantly so you can debug authentication issues, inspect what claims an API is actually sending, or check when a token expires — all without needing a backend, a CLI tool, or pasting sensitive tokens into a third-party server, since everything runs locally in your browser.
When to Use This Calculator
- Debugging why an API rejects a token by inspecting its claims and expiration time
- Checking a token's expiration time during a support investigation or incident response
- Verifying that an SSO or OAuth provider is issuing the claims your application expects
- Learning how JWTs are structured for interview preparation or security coursework
- Inspecting a token captured from browser dev tools or server logs to understand its contents
- Comparing the header algorithm between tokens to debug algorithm-mismatch authentication failures
Steps:
- Paste your JWT into the input box, or click "Load Sample" to try one.
- The header and payload are decoded automatically as you type.
- Review claims like iss, sub, exp, and iat in plain readable form.
- Timestamp claims (exp, iat, nbf) are automatically converted to readable dates.
Formula
JWT = base64Url(header) + "." + base64Url(payload) + "." + base64Url(signature)
Decoding: split on ".", base64Url-decode the first two parts, parse as JSON.
Verifying (not done here): HMACSHA256(base64Url(header) + "." + base64Url(payload), secret) === signature
Use Cases
- Debugging why an API rejects a token by inspecting its claims
- Checking a token's expiration time during a support investigation
- Verifying an SSO or OAuth provider is issuing the claims you expect
- Learning how JWTs are structured for interview prep or coursework
- Quickly inspecting a token pasted from browser dev tools or server logs
Key Benefits
- Decode any JWT instantly without a backend or CLI tool
- Everything runs client-side — tokens are never sent to a server
- Automatically converts timestamp claims to readable dates
- Free, no sign-up, works on any JWT regardless of algorithm
Pro Tips
- Always check 'exp' first when debugging an "unauthorized" error — an expired token is the most common cause
- Cross-reference the 'alg' in the header with what your backend expects to catch algorithm-mismatch bugs
- Never trust a decoded payload as proof of identity without verifying the signature server-side
- Use short-lived tokens with refresh tokens instead of long-lived JWTs to limit exposure if one leaks
Common Mistakes to Avoid
- Assuming a decoded JWT is a verified JWT — decoding only reads the content, it doesn't confirm authenticity
- Storing sensitive data (passwords, secrets) in the payload, forgetting it's readable by anyone
- Pasting production tokens into untrusted online decoders
- Confusing 'exp' (expiration) with 'iat' (issued at) when debugging token lifetime issues
Key Terms Explained
- Claim: A piece of information asserted about a subject, like a user ID or role
- Header: The first JWT segment, specifying the signing algorithm and token type
- Payload: The second JWT segment, containing the actual claims
- Signature: The third JWT segment, used to verify the token hasn't been altered
Related Concepts
Example
A token starting with eyJhbGciOiJIUzI1NiJ9 decodes to a header of {"alg":"HS256","typ":"JWT"} — telling you the token is signed with HMAC-SHA256.
Interpreting Your Results
The decoder splits the JWT on the two dot separators and Base64URL-decodes the first two segments. The header tells you the signing algorithm (like HS256 or RS256) and token type. The payload contains the actual claims — user identity, permissions, and timestamps.
Timestamp claims (exp, iat, nbf) are automatically converted from Unix epoch to readable dates. If 'exp' shows a date in the past, the token is expired and most servers will reject it. The 'sub' (subject) claim typically contains the user ID, and 'iss' (issuer) identifies the server that created the token.
Remember that decoding is not verification. The signature section is displayed but cannot be verified without the secret or public key. A decoded payload is informational only — never trust it as proof of identity without server-side signature verification.