JWT Decoder
Paste a token to read its header and claims, find out whether it has expired, and — if you have the key — check that the signature is genuine. A token is a credential, and this one never leaves your browser.
Runs entirely in your browser — nothing is uploaded
Header
Payload
What the claims mean
| Claim | Value | Meaning |
|---|
Signature
Decoding a token proves nothing about it. Anyone can write a JWT that says anything — only the signature says it came from who it claims to. Paste the key to check.
What this does
A JSON Web Token is three chunks of base64 joined by dots: a header saying how it was signed, a payload of claims, and a signature. This unpacks the first two into readable JSON, explains which claims are standard and what they're for, works out whether the token has expired, and — if you paste the key — checks that the signature is genuine.
All of it happens in this page. That is the reason to use this one rather than the first decoder a search turns up: a JWT is a bearer credential, and whoever holds it can act as the person it was issued to until it expires. Pasting a live token into a website hands over an account. Here it is read by JavaScript in your own browser and sent nowhere — you can confirm that by opening the network panel, or by disconnecting from the internet and carrying on.
Decoding is not verifying
This is the thing most worth understanding about JWTs. The payload is not encrypted — it's merely encoded, and anyone who has the token can read it, which is why nothing secret should ever go in one. Equally, anyone can write a token that claims to be an administrator. What stops them is the signature: a value only someone with the key could have produced over exactly those bytes.
So the claims you see below are only what the token says. They mean something once the signature checks out against a key you trust — and not before.
Checking the signature
Paste the key and press the button. What to paste depends on how the token was signed, which the header's alg tells you:
- HS256, HS384, HS512 use one shared secret for both signing and checking. Paste that secret. If your issuer publishes it base64-encoded, tick the box.
- RS256, PS256, ES256 and their larger relatives use a key pair. Paste thepublic key — either a PEM block beginning
-----BEGIN PUBLIC KEY-----, or a JWK, which is what you'll find at an issuer's/.well-known/jwks.json. A private key is never needed to check a signature and should never be pasted anywhere.
The check runs through your browser's own WebCrypto, the same implementation that secures the connection you're reading this over. Your key is used and discarded; it isn't stored or sent.
When a token has expired
exp is the moment a token stops being accepted, nbf the moment it starts, and iat when it was issued. All three are counted in secondssince 1970 — not milliseconds, which is the single most common mistake when writing tokens by hand. A token whose exp is in milliseconds appears valid for fifty thousand years, and this will say so.
Things worth worrying about
"alg": "none" means the token is unsigned — its contents can be changed by anyone. It exists in the specification for unusual cases, and there was a famous round of vulnerabilities where libraries accepted such tokens as though they were signed. If you see it on a token that is meant to be trusted, something is wrong.
A missing or empty signature on a token whose header claims an algorithm is the same problem wearing a different hat.
Sensitive data in the payload. Anything in there is readable by anyone holding the token. Names and IDs are normal; anything you would not put on a postcard is not.
Is my token private?
Yes. Neither the token nor the key is uploaded, logged or stored — the page has no server to send them to. This matters more than usual for this particular tool, and it's worth being just as careful elsewhere: if you have already pasted a production token into some other decoder, treat it as leaked and rotate it.
Frequently asked questions
My token has five parts and won't decode.
Then it's a JWE — an encrypted token rather than a signed one. Its contents are ciphertext, and without the decryption key there is genuinely nothing to show. This tool will tell you that's what you have rather than pretending it failed.
Why does it say the signature is invalid when the token works fine?
Usually the wrong key. Issuers rotate keys and publish several at once — check the header'skid and pick the matching key from the JWKS. Failing that, make sure you're pasting the public key rather than a certificate, and that nothing was truncated in the copy.
Can I edit the claims and re-sign it?
Not here. That's a token-minting tool rather than a decoder, and it needs a private key — something better kept in your own environment than typed into a web page, however local.
Does it check the issuer or audience for me?
No, and no decoder should: only your application knows which issuer and audience it ought to accept. Both claims are shown and explained; comparing them with what you expect is a decision, not a calculation.