JWT Decoder

A JSON Web Token looks like an unreadable blob of characters, but it's really just three Base64URL-encoded parts joined by dots: a header, a payload, and a signature. Decoding the header and payload isn't encryption at all — anyone with the token can read the claims inside, which is exactly why sensitive data should never be stuffed into a JWT payload. The problem is that the tokens people need to inspect are rarely disposable test data. They're often a live session token from a production app, an API access token, or a login cookie pulled straight from the browser's dev tools while debugging — a real credential that, in the wrong hands, grants real access. Pasting that into a random website hands your session to a server you know nothing about.

This tool never does that. The header and payload are decoded with plain JavaScript running in your browser the instant you paste a token — split on the dots, Base64URL-decoded, parsed as JSON — and none of it is transmitted anywhere. Signature verification works the same way, using the Web Crypto API (`SubtleCrypto`) that's built into every modern browser: HMAC algorithms (HS256, HS384, HS512) are verified against a secret you type in, and RSA algorithms (RS256, RS384, RS512) against a public key you paste in PEM format. Both the cryptographic secret and the verification itself stay local to the tab; refresh the page and everything — token, secret, key — is gone.

Paste a token to see its header and payload pretty-printed, along with a read-out of the standard `exp`, `iat`, and `nbf` claims converted to a human-readable date, with a clear "Expired" badge if the token's `exp` has already passed — handy for confirming a bug report of "I got logged out" is really just an expired token. If the algorithm is HS256/384/512 or RS256/384/512, enter the matching secret or public key to check whether the signature is genuine or has been tampered with. Algorithms outside that set (like ES256 or the unsigned `none`) still decode fine, but verification isn't offered rather than faking a result. For local development, the editable header/payload boxes let you tweak a claim — say, change a user ID or a role — and re-sign the token with the same HS256 secret your test server uses, which is a common way to test authorization logic without spinning up a full login flow.

Because a JWT's payload is plain, readable JSON once decoded, it pairs naturally with the JSON Formatter & Validator tool if you need to inspect a deeply nested claim more closely. One security reminder worth repeating: since decoding requires no secret at all, treat any token as sensitive the moment you're done inspecting it, and rotate credentials that were only ever meant to be short-lived if you're not certain where else they've been pasted before landing here.