JWT Decoder

About this tool

A JSON Web Token is three pieces of Base64URL-encoded JSON, joined by periods: a header describing the token type and signing algorithm, a payload carrying the actual claims — who the token represents, when it was issued, when it expires, and whatever custom data the issuer chose to include — and a signature, which is a cryptographic proof that the header and payload haven't been altered since the token was signed. The three pieces are visually distinct once you know to look: header.payload.signature, each segment Base64URL-encoded independently.

The header and payload are only encoded, not encrypted — this is the single most important thing to understand about JWTs and the source of more security mistakes than almost anything else in web authentication. Anyone who has a JWT, whether they were meant to have it or not, can decode the header and payload and read every claim inside in plain text, with no key, password, or special tool required — this decoder does exactly that, and so does a five-line script in any language. What the signature actually protects is integrity, not confidentiality: it lets a server that knows the signing secret (or has the issuer's public key, for asymmetric algorithms) verify that the payload hasn't been tampered with since signing. It says nothing about whether the payload should be kept secret from whoever's holding the token.

This distinction is why decoding a JWT and verifying one are different operations with different security implications. Decoding — what this tool does — just reads the Base64URL segments back into readable JSON, which requires no secret and proves nothing about the token's authenticity; a completely forged token with an invalid signature decodes exactly as cleanly as a legitimate one. Verifying a token means recomputing the signature using the secret or public key and confirming it matches, which is what actually establishes that the token is genuine and unmodified — and that step has to happen server-side, using a proper JWT library, with the real signing secret, which is never something a client-side browser tool should have access to. This tool intentionally does not attempt verification for exactly that reason: entering a signing secret into a browser tool defeats the purpose of keeping it secret, and a decode-only tool is the honest, safe scope for something that runs entirely client-side.

The payload's registered claims worth knowing at a glance: exp (expiration time) and iat (issued-at time) are both Unix timestamps, which this tool converts to readable dates and checks against the current time to flag whether a token has already expired — a surprisingly common source of "why am I logged out" bugs that's much faster to diagnose by eye than by writing a script. sub typically identifies the token's subject (often a user ID), and iss identifies the issuer. Beyond the registered claims, most real-world tokens carry custom application-specific data — roles, permissions, tenant IDs — which show up in the decoded payload exactly as the issuer put them there.