JWT decoder

Making sense of the claims inside

Once a token is decoded, the payload is mostly a handful of short, standardised fields called claims. The ones you will meet constantly: iss names the issuer that created the token, sub identifies the user or subject it is about, aud names the audience — the API it is meant for — while iat records when it was issued and exp when it stops being valid. Anything else in there is custom: roles, e-mail addresses, feature flags, whatever the issuing system decided to pack in. The time claims trip people up because they are plain Unix timestamps, seconds since 1970 — a number like 1784528768 rather than a readable date — so the token's whole lifetime hides in two unassuming integers.

Debugging a rejected token

When an API answers 401 and you are sure the token is right, work down a short list. First, if you copied it from an Authorization header, strip the word Bearer and the space in front — with those attached it is not a valid JWT and will not even decode. Next, read exp and check it is actually in the future: paste the number into the Unix timestamp converter and you will see the expiry as a real date, often revealing a token that died hours ago. Then compare aud and iss against the API you are calling — a token minted for the staging environment is routinely, and correctly, refused by production. And remember a minute of clock skew between servers is enough to make a freshly issued token look not-yet-valid.

Tokens this tool cannot open

Not everything that guards an API is a readable JWT. A token with five dot-separated parts instead of three is a JWE — genuinely encrypted, not merely encoded — and nothing readable comes out without the key, here or anywhere else. And plenty of session tokens are simply opaque random strings that were never JWTs to begin with; if it does not start with something like eyJ, there is likely nothing to decode. For the tokens that do open, it helps to remember what you are looking at: three blocks of Base64URL text glued together with dots. The Base64 tool decodes any single block on its own, which is a nice way to see with your own eyes that the readable parts of a JWT were never secret in the first place.

What decoding a JWT does and doesn't tell you

A JWT's header and payload are just Base64URL-encoded JSON — anyone can decode and read them, no secret required, which is exactly what this tool does. What it can't do is verify the signature: that needs the issuer's secret or public key, which is deliberately not something you'd paste into a random website.