How this converter works
A JWT is three base64url segments separated by dots: a header naming the algorithm, a payload of claims, and a signature over the first two. Paste one — with or without a Bearer prefix, quotes or line breaks — and the decoder pretty-prints the header and payload, keeping large integers and duplicate keys exactly as the issuer wrote them.
Decoding is just base64, so the token was never secret; the security comes from the signature. To check it, put the key in “Secret or key”: the shared secret for HS256/384/512 (as text, base64 or hex), or the issuer's public key for RS, PS, ES and EdDSA tokens as PEM, an X.509 certificate, a JWK or a whole JWKS — the key matching the token's kid is picked automatically. Verification runs in pure TypeScript inside this tab; nothing is uploaded. The example token's secret is codemaxxed-example-secret-32-bytes.
Every claim is explained — registered claims (iss, sub, aud, exp, nbf, iat, jti), OpenID Connect claims (email, nonce, azp, auth_time…) and common provider claims — and the validity timeline shows when the token was issued, when it starts and stops being valid, its lifetime and the time left. Set a clock skew or a “Check at” time to see whether a token was valid when a request failed.
Warnings point out real problems: alg none, algorithm confusion, tokens signed with well-known secrets, short HMAC secrets, missing exp, very long lifetimes, exp in milliseconds, jku/jwk header injection, duplicate claims and secrets left in the payload.
Switch to Encode & sign to build a token from a JSON payload (or re-sign an existing token): pick the algorithm, add header fields such as kid, optionally stamp iat/exp, and sign with a secret or a private key. For asymmetric keys the matching public JWKS is shown so you can configure the verifier.
Frequently asked
Is it safe to paste a JWT or a secret here?
Decoding, verification and signing all run in your browser — the token and key are never uploaded. That said, a JWT is a bearer credential and a signing secret lets anyone mint tokens. Prefer test tokens and test keys, and rotate any production secret you've pasted somewhere you don't control.
Which algorithms can it verify?
HS256, HS384 and HS512 with a shared secret; RS256/384/512 and PS256/384/512 with an RSA key; ES256, ES384, ES512 and ES256K with an EC key; and EdDSA/Ed25519. Keys can be PEM (public key, certificate, PKCS#1/PKCS#8/SEC1), bare base64 DER as Keycloak shows it, a JWK or a JWK Set.
Why does my HS256 token say invalid with the right secret?
Usually the secret encoding: some platforms store the secret base64-encoded, so its bytes differ from the text. The tool tries the other encodings and stray whitespace for you and tells you which one matches.
Why is my token showing as expired when it just worked?
Check the clock skew — servers often allow 30–300 seconds of leeway. Also exp is in seconds, not milliseconds: writing Date.now() instead of Math.floor(Date.now() / 1000) produces a date tens of thousands of years away, which the tool flags.
What does alg: none mean?
The token claims to be unsigned. A correct server must reject it. If your verification library accepts none, or lets the token's header choose the algorithm, that is a critical vulnerability — always pin the expected algorithm on the server.
Can it decrypt JWE tokens?
No. Five-segment JWE tokens are recognised and their header is shown, but the payload needs the recipient's decryption key.