JWT Decoder

A JSON Web Token (JWT, RFC 7519) is a compact, URL-safe credential made of three Base64url-encoded segments separated by dots: header, payload, and signature. The header declares the signing algorithm (alg) and token type (typ); the payload carries the claims; the signature binds the first two parts to a secret or private key so a server can detect tampering.

This decoder splits the token on the two dots, normalizes the Base64url alphabet (replacing - and _ with + and /, then re-padding with = to a multiple of 4), and runs each segment through the browser's built-in atob() function. The resulting JSON strings are parsed with JSON.parse and rendered as a key-value table. No third-party JWT library is loaded — the work is straightforward enough that browser primitives handle it.

Standard registered claims are decoded with extra context. Numeric date claims (exp, iat, nbf) are treated as Unix epoch seconds and converted to local time using new Date(value * 1000). The expiry indicator compares exp to Math.floor(Date.now() / 1000) and shows whether the token is currently valid or how long ago it lapsed.

Crucially, this tool does not verify signatures. Signature verification requires the secret (for HMAC algorithms like HS256) or the public key (for RS256, ES256, EdDSA). Putting either of those in a browser would defeat their purpose, so verification belongs on the server with a library like jsonwebtoken (Node), jose, PyJWT, or jjwt. Decoding without verifying is fine for inspection but never sufficient to trust a token.

Be aware of the alg: none vulnerability — older JWT libraries would accept a token whose header said "alg": "none" with no signature attached. Modern libraries reject this, but if you receive a token with that header value from a third party, treat it as suspicious. Likewise, watch for confused-deputy attacks where an HS256 token is verified with a public key as the HMAC secret.

The decoder also helps catch common mistakes: tokens missing the third segment (which means the issuer used an unsigned JWS), tokens whose payload contains stringified JSON instead of a JSON object, and tokens with kid (key ID) headers pointing at rotated keys. Each of those shows up clearly in the parsed view.

Everything runs locally. Your token is never sent to a server, logged, or stored. Closing the tab discards it. That said, a JWT payload often contains real user identifiers and scopes, so avoid pasting production tokens on shared machines or screen-recorded sessions.