JWT decoder

Three pieces of text joined by dots

Once you’ve signed in to a website, the server has to recognize you again on the next request. A common way to do that is to hand your browser a short signed note saying “this is user 48213, allowed to read orders, until 3:15 pm”. That note is a JSON Web Token, or JWT.

A JWT looks like one long random string, but it always has the same shape, header.payload.signature.

• The header is a small JSON object that names the signing algorithm (alg) and often the key that was used (kid).
• The payload is a JSON object of claims, which are statements such as sub (who), aud (for which service) and exp (until when).
• The signature is a seal computed from the first two pieces and a key.

Header and payload are written in Base64URL, a way of spelling bytes with letters, digits, - and _ so they survive a trip through an address or an HTTP header. That’s also why almost every token starts with eyJ, which is how {" comes out in that encoding.

Encoded isn’t encrypted

Base64URL is a spelling. It locks nothing, and turning it back into text takes no key, which is all this page does. So a signed JWT hides nothing at all. If the payload holds an email address, a role or an internal ID, anyone who gets hold of the token can read it, whether that’s a browser extension, a proxy log or a screenshot.

What you get from the signature is integrity. Change one character of the payload and the seal no longer matches, so the server refuses the token. People can still read it. They just can’t rewrite it.

What this page reads, and what it flags

The decoder strips a leading Bearer, spaces and line breaks, splits the token and prints the header and payload as formatted JSON. Then it goes through the claims one by one. The three dates, exp, nbf (not before) and iat (issued at), are numbers of seconds since January 1, 1970. You see them in your time zone and in UTC, with a live count such as “valid for 12 more minutes”.

You also get a word on the algorithm. HS256 uses one shared secret to sign and to check. RS256, ES256 and EdDSA use a key pair, where a private key signs and a public key checks, so services that only check tokens can’t create them.

What decoding can’t tell you

This page doesn’t check the signature. That would take the issuer’s secret or public key, and a page that asks for your signing secret is a page to close. As a result, a forged token and a genuine one look the same here. Read the output as “this is what the token claims”, never as “this token is valid”.

For the same reason, “not expired” only means exp is later than your device’s clock. The server may have revoked the token an hour ago.

If you’re writing the receiving side, the checks that count happen in your code. Accept only the algorithms you expect, verify the signature with a key you already trust, then compare iss, aud and exp with what you expect. Use a maintained library and never branch on the alg the token asks for.

A live token is a credential

Until it expires, a bearer token works for whoever presents it. Paste a production token into a website and you’ve handed it to that website, unless the decoding happens in your browser. Here it does. No request carries the token, it isn’t written to the address bar and it isn’t saved in browser storage. You don’t have to take our word for it: watch the network tab of the developer tools, or load the page and go offline before pasting.

Even so, the safest habit is to debug with tokens from a test account or with expired ones. If a real token ends up in a chat, a ticket or a public log, sign out everywhere or ask the issuer to revoke it.