JWT Decoder & Verifier

Read what is inside a JSON Web Token, and check its signature — without pasting a live credential into somebody else's server.

Claims

Signature

Verification runs in this tab using the Web Crypto API. Nothing you paste — token, secret or key — is ever sent anywhere.

Signature not checked — paste a secret or public key above.

🔒 Runs entirely in your browser — nothing you type is uploaded or stored on a server.

Paste a token and you immediately see its three parts decoded: the header (which algorithm signed it), the payload (the claims), and a claim-by-claim table where the timestamp claims are shown as real dates rather than ten-digit numbers. exp, nbf and iat are the ones people squint at, so they are rendered as “14 March 2026 09:31 UTC (in 3 hours)” and the page says plainly whether the token has expired.

Also on Txtset: decode a plain base64 string instead · read a Unix timestamp on its own.

Where this runs matters more than usual. A JWT is frequently a live credential — anyone holding it can act as its subject until it expires. Pasting one into a web service means transmitting a working key to a third party. Every part of this page runs in your browser: the decoding, the claim table, and the signature check. The token, the secret and the public key are all read from the fields in front of you and never sent anywhere.

Signature verification is included, using the Web Crypto API that is already in your browser — HMAC (HS256/384/512) with a shared secret, and RSA, RSA-PSS or ECDSA with a PEM public key. There are exactly three outcomes and the page never blurs them: verified, does not match, or not checked. A decoder that shows you a green tick for merely decoding a token is worse than useless, because decoding proves nothing at all — anyone can read a JWT, that is what base64url means.

Two things this deliberately does not do. It will not fetch a JWKS URL to find a key for you, because that would mean this page making requests on your behalf to a host named inside an untrusted token. And it never reads a token from the address bar — no URL parameter on this site is read into the page, so a token cannot end up in your history, in a bookmark, or in a referrer header.

How to use

  1. Paste the token. It decodes as you type; a leading Bearer is ignored.
  2. Read the header, the payload and the claims table — timestamps are converted for you.
  3. To check the signature, paste the shared secret (for HS256 and friends) or a PEM public key (for RS, PS and ES algorithms).
  4. Press Verify signature. You get verified, not matching, or a plain statement that it was not checked.

Examples

A standard token
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.… decodes to a header of {"alg": "HS256"} and a payload of {"sub": "1234"}.
An expired token
A payload with exp in the past is flagged “This token expired 6 days ago” rather than leaving you to convert the number.
alg: none
A token claiming no algorithm is flagged as proving nothing — that is the classic JWT vulnerability, and it should never verify.

Frequently asked questions

Is my token sent anywhere?
No. Decoding, the claims table and the signature check all run in this tab using your browser's own Web Crypto API. The token, any secret and any public key stay on your device. This page also never reads a token from the URL, so it cannot leak into your browser history or a referrer header.
Does decoding a JWT prove it is genuine?
No, and this is the single most misunderstood thing about JWTs. The header and payload are only base64url-encoded, not encrypted — anyone who has the token can read them, and anyone can write a token with any claims they like. Only the signature check tells you whether it was issued by someone holding the key.
Which algorithms can it verify?
HS256, HS384 and HS512 with a shared secret; RS256/384/512, PS256/384/512 and ES256/384/512 with a PEM public key. Anything else decodes normally but reports the signature as not checked, rather than implying a result it did not compute.
Can it fetch the key from a JWKS URL?
No, on purpose. Following a URL found inside an untrusted token would make this page issue requests to a host the token's author chose. Fetch the JWKS yourself and paste the matching public key.
What does <code>alg: none</code> mean?
It means the token carries no signature. It exists in the spec for tokens whose integrity is guaranteed some other way, but it is also the classic JWT attack: strip the signature, set alg to none, and a badly configured library accepts it. This page flags it rather than showing anything that looks like a pass.
My token has five parts and will not decode. Why?
Five dot-separated parts means it is a JWE — an encrypted token, not a signed one. Its contents cannot be read without the decryption key, so no decoder can show you the payload.
Is the payload encrypted?
No. A standard JWT is signed, not encrypted. Never put anything secret in a payload — passwords, keys, personal data — because every holder of the token can read all of it.

Related tools

Base64 Encode / DecodeConvert text to Base64 and back — with full UTF-8 support and a URL-safe option — instantly and privately in your browser.Hash GeneratorCompute MD5, SHA-1, SHA-256, SHA-384 and SHA-512 hashes of any text at once — instantly and privately in your browser.JSON FormatterBeautify, minify and validate JSON — with sorted keys, custom indentation and precise error locations.Timestamp ConverterConvert Unix epoch time to a human date and back — seconds or milliseconds, local time or UTC, with ISO 8601 and relative time.SQL FormatterTurn one long unreadable query into indented SQL you can review — in your browser, with your query never leaving the tab.