JWT decoder and validator

A JSON Web Token is three base64url-encoded parts separated by dots: a header saying how it was signed, a payload of claims, and a signature over the first two. The first two parts are merely encoded, not encrypted — anyone holding the token can read them. The signature is what stops the contents being altered.

That is precisely why pasting a live token into a random website is a bad habit. Many tokens are bearer credentials: whoever holds one can act as the user it identifies until it expires. A decoder that sends your token to a server is handing over a working key. This one does the decoding in your browser, and the HMAC verification too, using the browser's own WebCrypto implementation.

How to use this tool

1. Paste the token. A leading Bearer is stripped automatically, so you can paste straight from an Authorization header.
2. Read the claims summary. Issuer, subject, audience, issue time and expiry are decoded and shown in your local timezone with a plain-language relative time.
3. Check the expiry line. An expired token is called out in red — this explains most unexpected 401 responses.
4. For an HS256, HS384 or HS512 token, enter the shared secret and press verify. The signature is recomputed locally and compared.
5. Copy the payload if you need it elsewhere.

Worked example

Common use cases

• Working out why an API request returns 401 or 403
• Checking what claims your identity provider actually issues
• Confirming that two environments share the same signing secret
• Reading the expiry of a token during an incident
• Explaining token contents to someone during a code review
• Verifying a webhook signed with a symmetric key

Common mistakes

• Treating decoding as verification — Anyone can decode a JWT. Only checking the signature proves it has not been altered — always verify server-side before trusting a claim.
• Accepting alg: none — A token declaring none is unsigned. A server that honours that header can be handed any claims at all. This tool flags it in red.
• Putting secrets in the payload — The payload is encoded, not encrypted. Anything you put there is readable by the holder of the token.
• Confusing seconds and milliseconds — exp, iat and nbf are seconds since the epoch. Passing a JavaScript millisecond timestamp puts the expiry about fifty thousand years into the future.

Frequently asked questions

Is my token sent anywhere?

No. Decoding is base64url plus JSON parsing, and the HMAC check uses your browser's built-in WebCrypto. Both happen in the page. Nothing is transmitted — which matters, because a live token is usually a working credential.

Why can I not verify an RS256 token?

RS256 and ES256 use asymmetric keys: verification needs the issuer's public key, usually fetched from a JWKS endpoint. Since this page makes no network requests, it cannot fetch that key. Symmetric HMAC tokens can be verified because you supply the secret yourself.

What do the standard claims mean?

iss is the issuer, sub the subject (usually the user), aud the intended audience, iat when it was issued, nbf the earliest time it is valid, and exp when it expires. All three times are seconds since 1 January 1970 UTC.

The token decodes but the signature fails — why?

Most often the secret is wrong, has trailing whitespace, or is base64-encoded in your configuration while being used raw here. It can also be an algorithm mismatch, or a token altered in transit — which is exactly what the signature exists to detect.

Is it safe to paste a production token here?

It never leaves your browser, so no request carries it. That said, the safest habit with any tool is to use an expired or test token when you can. You can verify the claim by disconnecting from the internet and confirming the page still works.

Can I decode a token that is encrypted (JWE)?

No. This handles signed tokens (JWS), which is what almost every API uses. An encrypted JWE token has five parts rather than three and needs the decryption key.

Last updated 2026-09-26