JWT decoding
How JSON Web Tokens are structured, and how to read one safely
A JSON Web Token (JWT) is three base64url-encoded segments joined by dots: a header, a payload, and a signature — "header.payload.signature". The header names the signing algorithm (commonly HS256 or RS256) and token type. The payload carries claims: registered ones like `iss` (issuer), `sub` (subject), `aud` (audience), `exp` (expiration, as a Unix timestamp), and `iat` (issued at), plus whatever custom claims an application adds. The signature is what makes the token trustworthy — it's computed over the header and payload using a secret (HMAC) or private key (RSA/ECDSA), and only someone holding that secret or key can produce a valid one.
A common point of confusion: decoding a JWT and verifying a JWT are different operations. Because the header and payload are only base64url-encoded, not encrypted, anyone can decode them and read the claims without any key at all — that's just Base64. Verifying, by contrast, means recomputing the signature and checking it matches, which proves the token wasn't tampered with and actually confirms who issued it. A tool that only decodes cannot tell you whether a token is authentic; it can only show you what it claims to contain.
That distinction matters most when you're debugging a real token from a real system. Pasting a live, unexpired token into a random web-based decoder sends that token's full payload to that site's server — including whatever's in `aud`, `sub`, or custom claims — and if the decoder is also silently logging requests, that's a real token handled by a third party you didn't choose. We built JwtDecoder to do the whole decode step on-device, so debugging a production token doesn't mean trusting a stranger's server with it.
The app
How it compares to other tools
Frequently asked questions
What are the three parts of a JWT?
A JWT is header.payload.signature — three base64url-encoded segments separated by dots. The header specifies the signing algorithm and token type, the payload carries the claims (issuer, subject, expiration, and any custom data), and the signature is a cryptographic value computed over the first two parts that proves the token hasn't been altered.
Is decoding a JWT the same as verifying it's valid?
No. Decoding just reverses the base64url encoding to read the header and payload — anyone can do this without any secret or key, because that data isn't encrypted. Verifying means recomputing the signature with the correct secret or public key and checking it matches, which is what actually confirms the token is authentic and unmodified. A decoder alone can't tell you a token is trustworthy.
Is it safe to paste a real JWT into an online decoder?
Be cautious with tokens that are still valid (unexpired) and belong to a real account or system — even a purely client-side decoder still means the token's full contents pass through your browser to that page, and you generally can't verify a website's decoder isn't logging what you paste. For debugging live credentials, a local, offline tool avoids sending the token anywhere.
What do exp, iat, iss, sub, and aud mean in a JWT payload?
These are JWT's standard registered claims (defined in RFC 7519): `exp` is the expiration time as a Unix timestamp, `iat` is when the token was issued, `iss` identifies who issued it, `sub` identifies the subject (usually a user ID), and `aud` identifies the intended recipient or audience of the token. None of these are required, but most real-world JWTs use at least `exp` and `sub`.