JWT Decoder & Generator
Decode, verify and sign JWTs -- HS/RS/PS/ES algorithms, claims explained, test key generation.
What this tool does
Paste any JWT (JSON Web Token) to see its header and payload decoded and pretty-printed, every standard registered claim explained in plain English with its actual expiry status, and its signature checked against a secret or public key you provide. Switch to Build & Sign to construct and sign a new token with any of twelve algorithms — HS256/384/512 (shared secret), RS256/384/512 and PS256/384/512 (RSA, two padding schemes), or ES256/384/512 (elliptic curve) — and generate a throwaway test key pair on the spot if you don't already have one, so you can try the asymmetric algorithms without needing OpenSSL.
How a JWT is actually structured
A JWT is three Base64URL-encoded segments joined by dots:
header.payload.signature. The header names the signing
algorithm (and optionally a key ID). The payload
carries claims — the actual data, like who the
token is for and when it expires. The signature is computed over the
header and payload together, so changing either one invalidates it
if whoever checks the token actually verifies the
signature — the header and payload are only Base64URL-encoded, not
encrypted, so anyone can read them without the key; the signature is
what prevents anyone from forging or altering them undetected.
Standard claims, explained
This tool recognizes the registered claims from the JWT spec and
shows what each one means next to its actual value: iss
(issuer — who created the token), sub (subject — who
the token is about), aud (audience — who it's intended
for), exp (expiration time, with a live valid/expired
check), nbf (not valid before this time), iat
(issued at), and jti (a unique token ID, useful for
revocation lists). None of these are required or enforced by the
JWT format itself — a server has to actually check exp
for expiry to matter, for instance — but nearly every real system
uses most of them.
Choosing an algorithm, and a real security pitfall
HS* algorithms use one shared secret for both
signing and verifying — simple, but everyone who needs to verify a
token also needs the secret, which means they could also forge one.
RS*/PS*/ES* use a key pair: sign with the private
key, verify with the public key, so a token issuer can hand out the
public key freely and nobody who merely verifies tokens can forge
new ones. A genuinely dangerous real-world bug class is trusting the
alg field from an untrusted token at all — an attacker
who can submit "alg":"none" or swap an RS256 token's
algorithm to HS256 (then "sign" it with the known public key as an
HMAC secret) can sometimes bypass verification entirely on a
vulnerable server. A correct verifier pins the expected algorithm
itself rather than reading it from the token.
Privacy
Decoding, verifying, signing, and key generation all happen locally using the Web Crypto API. Nothing — not the token, not a secret, not a private key — is ever sent to a server.