Decode and verify a JWT

How to use it#

1. Paste the token, including all three dot-separated parts. Bearer in front, or the whole Authorization header line, is fine.
2. Read the header and payload. Beside them, the figures give the issue and expiry times and say whether the token is still valid.
3. Copy the header or the payload from the button beside its caption.
4. To check the signature too, paste the signing key: a shared secret for HS256, or a public key for RS256 and ES256. A whole JWKS works, and Key used says which key in it was used.

A JWT is encoded, not encrypted#

The three parts of a token are separated by dots and the first two are base64url, which is an encoding rather than a cipher. Anyone holding the token can read the payload, including in a browser console, without any key at all. That is what this page does.

It follows that a JWT payload is the wrong place for anything private. Email addresses, internal user ids, role names, and account status are all routinely put there, and all of them are readable by whoever holds the token, which on a web app usually includes the end user.

The signature is the part that carries trust. It proves the payload has not been altered since the issuer produced it, and checking it requires the key the issuer signed with. Paste that key into the Signing key box, under the decoded token, and this page will check it with the browser’s own crypto, not a server.

Why pasting a token into a website is a real risk#

A JWT is usually a live credential. Anyone holding it can act as the user it identifies until it expires, and expiry is frequently measured in hours. A token that reaches a server hands that server a working session.

From the outside, a page that decodes in your browser looks exactly like one that sends the token away. This page does the decoding in JavaScript in your tab, which you can confirm by opening your browser’s network panel and watching nothing happen when you paste.

If a token has already been pasted somewhere you are unsure about, the fix is to revoke or rotate it rather than to hope. Tokens are cheap to reissue and a leaked one is not something you can take back.

Verifying against a JWKS#

Issuers that sign with RS256 or ES256 publish their public keys as a JWKS, a JSON document with a keys list, usually at a URL ending in /.well-known/jwks.json. You can paste that whole document into the key box rather than digging out the one key you need.

The token header decides which key is used. Its kid field names a key, and only the key in the set with that kid is tried, as a real verifier would. If no key has that kid, the page says so and lists the kids the set does have, which usually means the issuer has rotated its keys and the token or the set is out of date. If the token has no kid, every key in the set that fits the algorithm is tried, and the page names the one that matched. The Key used row says which reading applied.

The claims worth reading first#

Three registered claims hold times, all of them in seconds since the Unix epoch rather than milliseconds: iat when the token was issued, nbf the point before which it should be rejected, and exp when it stops being valid. This page resolves all three to dates and says whether the token is currently inside that window.

The header is worth a glance too. Its alg field names the signing algorithm, and a token arriving with alg set to none is the classic attack: it asks the receiving system to accept an unsigned token as though it were signed. Any library written in the last several years rejects that, but it is still the first thing to look at when a token behaves strangely.