JWT Decoder and Generator
Decode a JWT and verify its HS, RS, PS or ES signature with your key, or sign a new one — the token and key never leave your device.
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 that identity providers such as Auth0, Okta, Cognito and Google 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.
Create a token on the same page
The Create side signs a new token from a JSON payload: with a secret for HS256, HS384 or
HS512, or with an RSA or elliptic-curve private key — pasted as PEM or JWK, or generated here as a test pair —
for RS256/384/512 and ES256/384/512. It can add iat, nbf and exp, and
fill sub, iss, aud and jti. Read and verify this
token brings the result back to this side, with the public key for an RS or ES token; a secret or a
private key is never carried across, and none of them goes into the page's address. Tokens made here are for
testing: real ones belong on the server that keeps the key.
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 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.
Which algorithms can it sign a new token with?
HMAC-based HS256, HS384, and HS512, which sign with a secret, and RS256, RS384, RS512, ES256, ES384 and ES512, which sign with a private key. The chosen algorithm is written into the token header as the alg field and used to sign the header-and-payload string.
Can it sign with an RSA or elliptic-curve key?
Yes. Pick an RS or ES algorithm and paste a private key as PEM or JWK, or generate a test key pair; the matching public key is shown, ready to copy for whoever verifies the token. A password-protected key or a public key is refused by name.
Can I set sub, iss, aud and jti, or give iat and nbf a time other than now?
Yes. Under "Registered claims" are fields for Subject (sub), Issuer (iss), Audience (aud) and JWT ID (jti); a filled field overrides that claim in the payload, a blank one leaves the payload as it is, and several audiences separated by commas become an array. Tick "Issued at (iat)" or "Not before (nbf)" and the date-and-time field beside it comes alive: leave it blank for the current second, or pick an instant in your local time to set the claim to it. Expires in still counts from now.