JWT Decoder — Inspect JSON Web Tokens

How JWT Decoding Works — and Why It's Not Verification

A JSON Web Token is three parts joined by dots: header.payload.signature. The header and payload are each JSON objects that have been Base64url-encoded — the same encoding family behind the Base64 tool, just with a URL-safe alphabet. Because Base64url is fully reversible without any secret, decoding the header and payload is a matter of splitting the token on its dots and running each of the first two segments through a standard decode function. That's exactly what this tool does: it takes the token you paste, decodes the first two segments, and renders the resulting JSON in a readable, colour-coded layout.

The third segment, the signature, is fundamentally different. It's not JSON and it's not meant to be decoded into something human-readable — it's a cryptographic value computed over the header and payload using an algorithm named in the header (commonly HS256, RS256, or ES256) and a secret or private key that only the issuing server holds. Verifying that signature means recomputing it with the correct key and checking it matches what's in the token. A decoder that only has the token — no key — has no way to perform that computation. This tool never asks for a secret or key because it isn't designed to verify anything; it only decodes and displays.

That distinction matters because a token that decodes cleanly here is not the same as a token that has been confirmed authentic. Anyone can construct a syntactically valid JWT with any payload they like — decoding it will succeed and produce readable JSON regardless of whether the signature is legitimate, forged, or entirely absent. In other words, decoding tells you what a token claims; only signature verification (performed with the correct key, typically server-side using a JWT library) tells you whether those claims can be trusted.

Despite that limitation, decoding alone is genuinely useful during development and debugging. If a login flow is misbehaving, or an API is rejecting requests with a token you believe should be valid, the fastest first step is usually to decode the token and look at its claims: is the exp timestamp in the past, is the aud or iss claim what the receiving service expects, does the submatch the user you think it should. Those checks don't require cryptography — they just require reading the JSON — and this tool makes that step instant instead of requiring you to manually split and decode Base64url segments by hand.