Debug authentication
Decode tokens to check common claims such as subject, issuer, audience, issued-at time, and expiration time.
Authentication tool
JWT Decoder
Decode JSON Web Token headers and payloads while debugging login flows, API requests, and authorization claims.
Ready
Use cases
Inspect token claims without leaving your browser.
Read header metadata
Inspect the algorithm and token type from the header before verifying the token in your backend or identity provider.
Common mistakes
Do not treat decoded claims as trusted data. Anyone can edit an unsigned payload, so verification is required before authorization.
Beginner guide
What a JWT is and why developers decode it.
A JSON Web Token is a compact string that carries claims between systems. Developers usually decode a JWT when they need to inspect the issuer, audience, subject, expiration, scopes, or custom claims that are influencing an API request. This page exists for that first inspection step. It makes the header and payload readable locally in the browser without changing the token or sending it to a server.
That said, decoding is only a visibility step. It does not prove the token is safe to trust. Use this page to understand what the token says, then let your API or identity platform verify the signature, issuer, audience, and timing rules.
Token anatomy
Header, payload, and signature each answer a different question.
Header
The header usually shows the token type, algorithm, and sometimes a key ID used for verification routing.
Payload
The payload contains claims such as issuer, subject, audience, expiration, scopes, roles, or tenant-specific custom data.
Signature
The signature protects integrity. It helps detect tampering, but it does not hide the payload from view.
Security warnings
A readable token is not automatically a trustworthy token.
Do not treat decoded claims as verified truth. Bearer tokens act like credentials, which means logging them in plaintext, sharing them in tickets, or storing them casually is a security risk. JWT payloads are normally encoded rather than encrypted, so confidential information should not be placed there unless a separate encryption strategy exists.
If you need to inspect the decoded payload more clearly, use the JSON Formatter. If the payload contains time-based claims such as exp, nbf, or iat, convert them with the Unix Timestamp Converter before assuming the token should still be accepted.
Example tokens
Read example claims before you debug a live authentication issue.
A typical access token may include claims such as iss, sub, aud, exp, and scope. A refresh token may look structurally similar but is meant for token renewal rather than everyday API authorization. If your system uses signed identity tokens, access tokens, and refresh tokens together, decode each one carefully rather than assuming they should all contain the same claims.
{
"iss": "https://auth.example.com",
"sub": "user-42",
"aud": "payments-api",
"scope": "payments:read",
"exp": 1785596400
}That example is easy to scan in JSON form. If the real-world token is difficult to compare with another sample, use the JSON Compare Tool to isolate the important differences.
Debugging workflow
Decode first, validate claims second, investigate keys third.
A reliable JWT debugging sequence is simple. Decode the token. Inspect the header for alg, typ, and kid. Inspect the payload for issuer, audience, subject, expiration, and scope claims. Convert time values. Compare a working token with a failing token. Only after those structural checks should you move into signature verification, key rotation, OAuth client configuration, or API gateway behavior.
If log pipelines or middleware are extracting bearer tokens incorrectly, validate the extraction pattern with the Regex Tester. If claims map into downstream APIs or SQL-backed authorization rules, the SQL Formatter and JSON cluster can help with broader root-cause analysis.
Best practices
Use the decoder as a support tool, not as a substitute for security controls.
Keep access tokens short-lived. Protect refresh tokens more carefully. Verify signatures with proven libraries. Check issuer and audience consistently. Keep claims small and purposeful. Avoid placing secrets in the payload. Redact live tokens from logs. These practices matter more than the convenience of being able to read the token quickly.
FAQ
JWT decoder questions.
Is decoding the same as verifying?
No. Decoding only reads the token. Verification checks whether the token was signed by a trusted issuer.
Can I decode expired tokens?
Yes. Expiration affects whether a token should be accepted, not whether its payload can be read.
Why does my JWT fail?
The tool expects a token with at least header and payload sections separated by dots.
What is the difference between an access token and a refresh token?
An access token is normally sent to APIs. A refresh token is normally exchanged for a new access token.
Can this page verify HS256, RS256, or ES256 signatures?
No. It can help you inspect the token, but real verification still belongs to your auth stack.
Why are time claims hard to debug?
Because exp, nbf, and iat are often Unix timestamps and are easy to misread during incidents.