Decode a JWT
Paste a token and its header and payload appear below, with the time claims resolved to dates. Add the signing key and it checks the signature too. Access tokens do not belong in a stranger’s form, so this one works in your tab.
How to use it#
- Paste the token, including all three dot-separated parts.
- Read the header and payload, and check the resolved expiry against the status line.
- Copy the header or the payload from the button beside its caption.
- To check the signature too, paste the signing key: a shared secret for HS256, or a public key for RS256 and ES256.
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 box under the claims 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. Pasting one into a decoder that posts it to a server hands that server a working session.
Most decoders are careful and decode in the browser, but from the outside the two are indistinguishable. 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.
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.
Frequently asked questions#
What do I need to verify a signature?
#
The key the token was signed with. For the HS algorithms that is the shared secret, which is a live credential; for RS, PS and ES it is the issuer’s public key, which is not secret and is usually published at a JWKS endpoint. Paste one into the key box and the check runs in your tab. Leave it empty and the token is only decoded, which proves nothing about who issued it.
Is it safe to paste a signing secret here?
#
The check uses the Web Crypto API in this tab and the secret goes nowhere, which you can confirm in your network panel. The caution is about the habit rather than this page: the next site that asks you for a signing key may not be built the same way. Public keys carry no such risk, so paste those freely.
Do other JWT tools send my signing key to a server?
#
Some have to. A page that verifies on its own back end cannot do the work without receiving your key first, and once a key reaches a server it can be logged, cached or stored, whether or not anyone meant it to. None of that is visible from the page itself, so the check is the same everywhere: open the network panel, paste, and watch whether a request goes out. If a signing key has already gone somewhere you are unsure about, rotate it rather than hope.
Is my token sent anywhere?
#
No. The decoding is plain JavaScript running in this tab. You can verify it by opening the network panel in your browser’s developer tools and watching for requests while you paste, because there will not be any.
Can I decode an encrypted token?
#
No. This page reads JWS tokens, which are signed and readable. A JWE token is genuinely encrypted, has five parts rather than three, and cannot be read without the decryption key.
Why does the expiry look like it is in 1970?
#
The claim was probably written in milliseconds. The specification says these are seconds since the epoch, so a millisecond value is a thousand times too large and a seconds value read as milliseconds lands just after 1970. The fix belongs in whatever issued the token.
Is it safe to put user data in a JWT?
#
Only data you are content for the user and anyone holding the token to read. The payload is encoded rather than encrypted. Keep anything sensitive server-side and reference it by an identifier instead.