JWT Decoder

Paste a JWT token in the input box and read the decoded header, payload, and signature in three labeled sections. Each section pretty-prints the JSON with syntax highlighting.

Use it to inspect what an authentication service is putting in your tokens, debug an API that's rejecting your request, or verify the contents of a third-party SSO assertion. Decoding happens entirely in the browser — the token is never sent to a server, which matters because tokens often contain claims you don't want shared.

The decoder does not verify signatures. It shows the algorithm in the header (HS256, RS256, ES256, etc.) so you know what would be needed for verification, but the cryptography happens in your auth library, not here.

A JWT (JSON Web Token) is three base64url-encoded parts separated by dots: header.payload.signature. The header is a JSON object describing the token (algorithm, type, sometimes a key ID). The payload is a JSON object containing the claims (subject, issuer, audience, expiration, plus any custom data). The signature is the HMAC or RSA/ECDSA signature over the encoded header and payload, ensuring tamper resistance. The decoder splits the three parts, base64-decodes the header and payload, and pretty-prints them.

Worked example. Paste a token that starts `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`. Decoder output. Header: {"alg": "HS256", "typ": "JWT"}. Payload: {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}. Signature: shown as the raw base64 string (not decoded into bytes for display, since it's not human-readable). The header tells you HMAC-SHA256 was used; the payload shows the claims; the signature is what your server verifies with the right key.

The registered claims worth knowing. iss (issuer): who created the token. sub (subject): who the token is about (typically a user ID). aud (audience): who the token is intended for (typically a service identifier). exp (expiration): when the token stops being valid (Unix timestamp in seconds). nbf (not before): when the token starts being valid. iat (issued at): when the token was created. jti (JWT ID): a unique identifier for revocation tracking. Custom claims (your application's user data) live alongside these. The decoder converts the timestamp claims to readable datetimes in your local timezone for quick checking.

Why verification doesn't happen here. To verify the signature, you need the secret (for HMAC algorithms) or the public key (for RSA/ECDSA). Pasting either into a third-party web tool defeats the purpose of having a secret. Verification belongs in your server-side code where the key already lives. The decoder is an inspection tool — debugging "is the payload what I expect?" — not a verification step. If a token decodes here but fails to verify on your server, the signature step is the problem; the contents are fine.

Tokens to never paste publicly. Anything from a production system. Long-lived refresh tokens. Access tokens for paid APIs (Stripe, Twilio). Even short-lived access tokens can leak information about user IDs, emails, or internal data structures. The decoder runs entirely in the browser — nothing transmits over the network — but operational security is a habit, not a feature you can opt into. Use test tokens for inspection; let your server-side libraries handle live tokens.