JWT decoder

What is a JWT?

A JSON Web Token (JWT, RFC 7519) is a compact, URL-safe way of carrying signed claims between parties. The token is three base64url-encoded segments joined by dots: header.payload.signature. JWTs started as a way to ship signed claims between services without server-side sessions, and they are now the default token format in OAuth 2.0 and OpenID Connect.

Decoding a JWT reveals the header (which algorithm signed it) and the payload (the claims). Decoding alone proves nothing about authenticity — verifying the signature with the issuer's key is what makes a JWT trustworthy.

How it works

The header advertises the signing algorithm in its alg field and optionally identifies the key with kid. The payload carries claims; registered claims include iss (issuer), sub (subject), aud (audience), exp (expiration as seconds since the Unix epoch), nbf (not-before), iat (issued-at), and jti (token ID).

The signature is computed over the ASCII string base64url(header) + "." + base64url(payload). With HS256 the signature is an HMAC using a shared secret; with RS256 or ES256it is an asymmetric signature verified using the issuer's public key, often distributed through a JWKS endpoint.

When to use this tool

• Inspecting a bearer token returned by an API to confirm the audience, expiry, and scopes.
• Debugging an OIDC ID token while wiring up Auth0, Okta, Cognito, or a self-hosted identity provider.
• Verifying that a service-to-service token carries the claims a downstream service expects.
• Learning the structure of OAuth 2.0 / OIDC tokens.
• Confirming a token was signed with the algorithm and key your verifier will accept.

Common pitfalls

• Verifiers that accept alg: none let an attacker forge any claims. Reject unsigned tokens at the library level.
• Algorithm-confusion attacks: a verifier configured for RS256 that also accepts HS256 can be tricked by a token signed with the public key as an HMAC secret. Pin the algorithm.
• Decoding is not verification. Anyone holding the token can read its payload — never put secrets in claims.
• exp and iat are in seconds. Date.now() in JavaScript returns milliseconds; dividing by 1000 is a frequent off-by-1000 bug.
• Putting tokens in URL query strings exposes them in server access logs, browser history, and Referer headers. Use the Authorization header instead.

Frequently asked

Does this verify the signature?

No. This tool decodes the header and payload only. Signature verification requires the issuer's key, which we don't have. Use a server-side library (jsonwebtoken, jose, PyJWT) for verification.

What is the difference between HS256 and RS256?

HS256 is symmetric: the same secret signs and verifies, so any party that can verify can also forge. RS256 is asymmetric: a private key signs, a public key verifies — appropriate when the verifier and signer are different services.

How do I get the public key for verification?

Most providers publish a JWKS document at a well-known URL (often /.well-known/jwks.json). Match the token's kid against an entry in the JWKS to find the right key.

Are my tokens uploaded anywhere?

No. JWT decoding runs entirely in your browser. The page makes no network calls with the token, and an automated CI check enforces this on every commit.

Why does my token verify here but fail in another tool?

Most often: a clock-skew failure on exp/nbf, an audience mismatch, or the other tool requiring a specific algthe token doesn't use. Check the verifier's configuration before assuming the token is wrong.