JWT Decoder
Decode and inspect JWT tokens
Checked in your browser with WebCrypto; the key and the token are not sent to our servers. HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512, and EdDSA (Ed25519, in browsers that support it).
About JWT Decoder
JWT Decoder shows the header and payload of a signed JSON Web Token as indented JSON, keeping large numbers exactly as written, and turns the exp, iat, and nbf claims into UTC dates with an expired or not-yet-valid note. It also verifies the signature locally with WebCrypto: a shared secret for HS256, HS384, and HS512, or a public key in PEM or JWK form for RS, PS, ES, and EdDSA (Ed25519) tokens. Unsigned tokens (alg none) and a public key offered for an HS token are refused. Encrypted tokens with five parts are not supported.
Example
An HS256 token decoded, then verified with the secret my-secret (the exp note depends on today's date; this token expired on January 1, 2026):
Token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0MiIsIm5hbWUiOiJBZGEiLCJpYXQiOjE3NjcyMjU2MDAsImV4cCI6MTc2NzIyOTIwMH0.tSbItJNpja-KxR9Sew4UseTRkf2DxToP11X65NZgLJw
Decode and Verify signature
HEADER
{
"alg": "HS256",
"typ": "JWT"
}
PAYLOAD
{
"sub": "42",
"name": "Ada",
"iat": 1767225600,
"exp": 1767229200
}
exp: 2026-01-01T01:00:00Z (UTC) — expired
iat: 2026-01-01T00:00:00Z (UTC)
Signature verified (HS256): this token was signed with this key and has not been changed. Check exp / nbf in the decoded payload as well.How to decode and verify a JWT
- 1Paste the token, three base64url parts separated by dots, and click "Decode".
- 2Read the header, the payload and, under it, the exp, iat, and nbf dates in UTC.
- 3To check the signature, paste the secret or the public key under "Verify the signature"; for an HS token, set "Secret is" to text or base64 / base64url.
- 4Click "Verify signature" to get "Signature verified" or "Invalid signature" with the reason.
Formats and limits
- Token format
- Signed JWT in compact form (three parts); encrypted tokens and unencoded payloads are not handled
- Algorithms
- HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512, and EdDSA (Ed25519, in browsers whose WebCrypto supports it)
- Keys accepted
- A secret as text or base64/base64url, an oct JWK, a PEM public key, or an RSA, EC, or OKP JWK
- Keys refused, with a reason
- JWK Sets, X.509 certificates, PKCS#1 RSA keys, and PEM private keys; a private JWK is reduced to its public part
- Not checked for you
- exp, nbf, iss, and aud: the dates are shown, the decision stays with your application
Where your token is processed
Decoding and signature checks run in this page with your browser's atob and WebCrypto; the token and the key are not sent to our servers. If you turn on a translation in the language menu, Google receives the text shown on the page, including the decoded header and payload, so keep translation off for real tokens. A failed decode sends us the message Invalid JWT token, the tool's name, and your browser's name and version.
Frequently asked questions
Does this tool verify the JWT signature?
Yes. Paste the shared secret for HS256, HS384, or HS512, or the issuer's public key as PEM or JWK for RS, PS, ES, or EdDSA, then click "Verify signature". The algorithm is read from the token header, and alg none is refused.
Is a verified token safe to accept?
Not by itself. A verified signature proves the token was signed with that key and has not changed since. Your application must still check exp, nbf, the issuer (iss) and the audience (aud); this page only shows them.
Why is my public key refused for an HS256 token?
Accepting it would allow the algorithm-confusion attack, where a public key is used as an HMAC secret. An HS token must be checked with its shared secret, so a PEM key or a non-oct JWK is refused for HS256, HS384, and HS512.
Why is my JWK Set or certificate refused?
The check needs one public key. From a JWK Set, paste the single key whose kid matches the token header. From an X.509 certificate, extract the key with openssl x509 -pubkey -noout, and convert a PKCS#1 RSA PUBLIC KEY to the PUBLIC KEY form.
Why does Decode say Invalid JWT token?
The text does not have three dot-separated parts, or a part is not base64url-encoded JSON. Encrypted tokens with five parts are not supported. Decode never looks at the signature, so a wrong signature cannot cause this message.
Tips and tricks
- ✓A secret copied from a .env file can end with a line break; with "Secret is" set to text, the verdict says so when the secret matches without it.
- ✓If a PS256 token was signed with another salt length, the verdict names that length and explains why conforming libraries reject it.