JWT Decoder

What is a JWT?

A JSON Web Token (JWT, defined in RFC 7519) is a compact, URL-safe way to represent claims between two parties. It's the most common format for stateless authentication on the web — when you log in, the server returns a JWT, and your client sends it on every subsequent request to prove who you are. The server can trust the token without a database lookup because the signature proves it issued the token and that nothing has been altered since.

Anatomy: three parts, two dots

A JWT is header.payload.signature. Each part is Base64url-encoded, and the dots are the separators — which is why a valid token always contains exactly two of them. Take a typical first segment, eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9: decode it and you get the header {"alg":"HS256","typ":"JWT"}, which names the signing algorithm. The second segment is the payload — the claims, such as who the user is and when the token expires. The third is the signature, computed over the first two segments using a shared secret (HMAC) or a private key (RSA, ECDSA). Decoding the first two parts needs only Base64; checking the third needs the key.

The standard claims worth knowing

• iss — issuer: who created the token.
• sub — subject: who the token is about, usually a user ID.
• aud — audience: which service the token is intended for.
• exp / nbf / iat — expiry, not-before, and issued-at, all Unix timestamps in seconds.
• jti — a unique token ID, useful for revocation lists.

Anything else in the payload is a custom claim — roles, permissions, tenant IDs. When you are debugging a 401, exp and aud are the first two fields to check: expired tokens and tokens sent to the wrong audience account for most rejections.

Decoding is not verifying

This is the single most important thing to understand about JWTs. Anyone can decode a token — this page does it with a few lines of Base64. Only someone holding the right key can verifyone. A decoded payload that looks legitimate proves nothing: an attacker can mint a token claiming to be any user in seconds. If your application ever reads claims from a token without first checking the signature, you do not have authentication; you have a suggestion box. Verification — and pinning the expected algorithm rather than trusting the header's alg field — must happen server-side, in your code or your gateway.

Common pitfalls

Base64url is not quite Base64: it swaps + and / for - and _ and drops the = padding, so a generic Base64 decoder will choke on many tokens. Tokens also grow quickly — every claim you add travels on every request, and a bloated JWT in a cookie can push you past header size limits. Finally, think about storage on the client: a token in localStorage is readable by any script that runs on your page, so an XSS hole becomes a stolen session. HttpOnly cookies trade that risk for CSRF concerns; whichever you choose, keep expiry short.

Why decoding tokens locally matters

Many JWTs include enough information to identify a user, an organization, or an internal API permission. Even an expired token still leaks identifiers. Pasting one into a server-backed tool means a third party logs your identity. This decoder runs in the browser; the token never leaves the page.

Related tools

• Base64 Encoder / Decoder — the encoding that underpins every JWT segment.
• JSON Formatter — pretty-print a decoded payload for easier reading.
• Random Token Generator — generate strong signing secrets and API keys.
• Hash Generator — explore the hashing that HMAC signatures are built on.