Debugging an OAuth / OpenID Connect login that's failing — paste the access or ID token, see what the IdP actually issued. Confirming token expiry: the tool decodes exp as a real date and flags it if it's in the past. Sanity-checking custom claims a backend is asserting (roles, permissions, tenant IDs). Reading a token your library "rejected as invalid" to see whether the issue is structural, expiry, or signature.

iss — issuer (who created the token) sub — subject (the user/account it represents) aud — audience (who should accept it) exp — expiry (Unix timestamp) iat — issued-at (Unix timestamp) nbf — not-valid-before (Unix timestamp)

A decoded JWT is NOT a verified JWT. The signature isn't checked here — that requires the issuer's public key (RSA/EC) or shared secret (HMAC). Decoded contents tell you what the token says , not whether you should trust it. Always verify on the server before honouring claims. Don't paste production tokens into anywhere. Anyone with a live JWT can impersonate the user until exp . The browser doesn't transmit it from this tool, but extensions, screen-recordings, and dev tools can. Use a fresh token from a test environment if you need to share. alg: none tokens are a known attack class. If a header has alg: none and your library accepts it, attackers can forge tokens. Reject this on the server. Time skew matters. A token's exp is checked against the verifier's clock. Servers with drift fail tokens that look valid here.

Decoding is not verifying. This tool — and every "JWT decoder" — only reveals the payload by splitting the three Base64 segments. It does not check the signature. A JWT that decodes successfully here can still be forged; only a verifier with the secret (HS256) or public key (RS256/ES256) confirms authenticity. Never trust JWT contents on the basis of "the decoder showed it." Algorithm confusion is the classic JWT exploit. A library configured to accept both HS256 (symmetric) and RS256 (asymmetric) can be tricked: an attacker takes the server's public key, signs a forged token with HS256 using that public key as the HMAC secret, and the misconfigured verifier accepts it. Always pin a single expected algorithm at verify time and reject tokens whose header specifies anything else. The header is part of the signed payload. Some developers assume the JWT header is unsigned because it sits before the signature. It isn't: the signature covers base64url(header) + "." + base64url(payload) . Tampering with the header invalidates the signature on a properly-implemented verifier. The vulnerabilities come from verifiers that pull the algorithm from the header before checking the signature. JWTs aren't sessions, and they don't revoke. Issued tokens are valid until exp . Logging a user out, banning them, rotating keys — none of that invalidates an issued JWT without additional infrastructure (revocation lists, short expirations + refresh tokens, or stateful session lookup). If you need instant revocation, JWT alone is not the right mechanism; pair with a server-side check or use opaque tokens. Don't put PII in a JWT. The payload is Base64-encoded, not encrypted. Anyone who intercepts the token (browser dev tools, server logs, error trackers like Sentry that capture request headers) can read every field. Use minimal claims — user ID, role, expiry. Anything sensitive belongs in a server-side session lookup keyed by the token's sub .

JWT Decoder

Paste a JWT to decode its header and payload. All decoding runs in your browser — tokens never leave the page.

JWT

Header

Enter input above to see the result.

Payload

Enter input above to see the result.

Signature (base64url, not verified)

Enter input above to see the result.

This tool decodes only — it does not verify the signature against a key. Treat decoded payload as untrusted until verified.

What is this for?

A JWT (JSON Web Token) is three base64url-encoded parts joined by dots: header.payload.signature. The header and payload are JSON objects you can inspect; the signature proves the token wasn't tampered with after issuance. This tool decodes the first two parts so you can see what's inside without the noise of base64 — useful when debugging auth flows, expired sessions, or "which user is this token for, exactly?".

When to use it

Debugging an OAuth / OpenID Connect login that's failing — paste the access or ID token, see what the IdP actually issued.
Confirming token expiry: the tool decodes exp as a real date and flags it if it's in the past.
Sanity-checking custom claims a backend is asserting (roles, permissions, tenant IDs).
Reading a token your library "rejected as invalid" to see whether the issue is structural, expiry, or signature.

Common claims

iss — issuer (who created the token)
sub — subject (the user/account it represents)
aud — audience (who should accept it)
exp — expiry (Unix timestamp)
iat — issued-at (Unix timestamp)
nbf — not-valid-before (Unix timestamp)

Common gotchas

A decoded JWT is NOT a verified JWT. The signature isn't checked here — that requires the issuer's public key (RSA/EC) or shared secret (HMAC). Decoded contents tell you what the token says, not whether you should trust it. Always verify on the server before honouring claims.
Don't paste production tokens into anywhere. Anyone with a live JWT can impersonate the user until exp. The browser doesn't transmit it from this tool, but extensions, screen-recordings, and dev tools can. Use a fresh token from a test environment if you need to share.
alg: none tokens are a known attack class. If a header has alg: none and your library accepts it, attackers can forge tokens. Reject this on the server.
Time skew matters. A token's exp is checked against the verifier's clock. Servers with drift fail tokens that look valid here.

Expert notes

Decoding is not verifying. This tool — and every "JWT decoder" — only reveals the payload by splitting the three Base64 segments. It does not check the signature. A JWT that decodes successfully here can still be forged; only a verifier with the secret (HS256) or public key (RS256/ES256) confirms authenticity. Never trust JWT contents on the basis of "the decoder showed it."
Algorithm confusion is the classic JWT exploit. A library configured to accept both HS256 (symmetric) and RS256 (asymmetric) can be tricked: an attacker takes the server's public key, signs a forged token with HS256 using that public key as the HMAC secret, and the misconfigured verifier accepts it. Always pin a single expected algorithm at verify time and reject tokens whose header specifies anything else.
The header is part of the signed payload. Some developers assume the JWT header is unsigned because it sits before the signature. It isn't: the signature covers base64url(header) + "." + base64url(payload). Tampering with the header invalidates the signature on a properly-implemented verifier. The vulnerabilities come from verifiers that pull the algorithm from the header before checking the signature.
JWTs aren't sessions, and they don't revoke. Issued tokens are valid until exp. Logging a user out, banning them, rotating keys — none of that invalidates an issued JWT without additional infrastructure (revocation lists, short expirations + refresh tokens, or stateful session lookup). If you need instant revocation, JWT alone is not the right mechanism; pair with a server-side check or use opaque tokens.
Don't put PII in a JWT. The payload is Base64-encoded, not encrypted. Anyone who intercepts the token (browser dev tools, server logs, error trackers like Sentry that capture request headers) can read every field. Use minimal claims — user ID, role, expiry. Anything sensitive belongs in a server-side session lookup keyed by the token's sub.