JWT Decoder
Decode a JWT and verify its HMAC or RSA/ECDSA signature with your secret or public key, plus a live expiry countdown. Token and keys never leave your device.
🔒 Everything runs in your browser — nothing is ever uploaded. HMAC (HS256/384/512) signatures are verified with your secret and RSA/ECDSA/EdDSA (RS/PS/ES, Ed25519) signatures with the public key you paste, all via the Web Crypto API.
Inspect and verify a JWT without sending it anywhere
Paste a JSON Web Token and instantly see its decoded header and payload, formatted as readable JSON.
Time claims (exp, iat, nbf) are shown as human dates, with a live
countdown to expiry. Enter the secret to verify HS256/384/512 signatures, or paste an
SPKI PEM or JWK public key to verify RS256/384/512, PS256/384/512 and
ES256/384/512 — the RSA/ECDSA algorithms real identity providers (Auth0, Okta, Cognito, Google)
actually sign with. Everything runs entirely in your browser with the Web Crypto API — your token, secret
and key are never uploaded.
Reading a token is not checking it
A JWT is three base64url strings joined by dots, and the middle one is the payload — not encrypted, just encoded. Anyone holding the token can read every claim in it, which is why a JWT is the wrong place for anything private: no password, no card number, nothing you would not put in a URL. Decoding tells you what a token says. Only checking the signature tells you whether to believe it, and that needs the key. Paste the secret or the public key here and the page will do it; without one, treat everything you see as a claim somebody made rather than a fact.
alg: none, and what a valid signature still does not prove
The header names the algorithm, and none is a legal value in the specification — a token with no
signature at all. Libraries that trusted the header over their own configuration have been the source of real
authentication bypasses, and this tool will decode such a token and show you exactly that, because seeing it is
the point. Even a signature that checks out proves only that the holder of the key issued this payload. It does
not prove the token reached you from the person it describes, that it has not been copied from somewhere else,
or that it is still in date — expiry lives in the exp claim and is checked separately.
Frequently asked questions
Which signatures can it verify?
HMAC (HS256/384/512) with the shared secret, and RSA/ECDSA (RS256/384/512, PS256/384/512, ES256/384/512) with a public key. Paste the public key as an SPKI PEM (-----BEGIN PUBLIC KEY-----) or a JWK — X.509 certificates and PKCS#1 keys are not accepted.
What does a green "verified" actually prove?
Only that the signature matches the key you supplied. It does not check the issuer (iss), audience (aud) or that the token is unexpired — verify those claims separately before trusting a token.
Is my token uploaded?
No. Decoding and verification happen locally in your browser, which matters because a JWT is often a live credential.
Is my token safe to paste here?
The decoding happens in your browser and nothing is uploaded. That said, a live token is a credential: if it is still valid, prefer to expire it afterwards, as you would with any secret you have pasted somewhere.
Why can I read the payload without a key?
Because it is encoded, not encrypted. Base64url is a way of writing bytes as text, not a way of hiding them. A JWT protects against tampering through its signature; it does not protect against reading.
The signature checks out — does that make the request legitimate?
It means the payload was issued by whoever holds the signing key and has not been altered since. It says nothing about who is presenting the token now, or whether it has expired — check the exp and nbf claims for that.