JWT Decoder
Paste a JSON Web Token to inspect its header, payload, registered RFC 7519 claims and signature segment. The decoder runs entirely in your browser. Signatures are displayed but not validated — that requires the issuer's key.
FAQ
Why doesn't this tool verify the signature?
JWT signatures are produced with either a shared secret (HS256/HS384/HS512) or an asymmetric private key (RS256, PS256, ES256, EdDSA). Verifying them requires the same secret or the matching public key, neither of which the browser can have. Pasting a production HMAC secret into a public web page in order to verify a signature would itself be a security incident — the page would have an opportunity to log it. The decoder therefore shows the signature bytes and the canonical signing_input so you can verify out-of-band with your own tooling: openssl dgst, jwt-cli, or your language's JWT library against a key you control.
Is alg:none really exploitable in 2025?
It is still being found in audits — usually in custom JWT handlers built without a library, or in libraries with permissive default verifiers. CVE-2015-9235 and CVE-2018-1000531 are the famous early examples. Modern libraries reject alg:none by default but a worrying number of in-house token handlers do not, especially in microservice meshes where one service trusts a token another service has 'verified'. If this decoder shows alg:none and the issuer is a production system, treat that as a critical finding until proven otherwise.
Are JWTs encrypted?
No, signed JWTs (the format with three dot-separated segments and the algorithms above) are signed but not encrypted. The header and payload are base64url-encoded plaintext that anyone can decode — exactly like this tool just did. Never put sensitive PII, secrets or internal IDs in a JWT payload that you would not also be comfortable writing on a postcard. JWE (JSON Web Encryption, RFC 7516) is a separate spec for encrypted tokens; it uses five segments, not three, and is rarely seen in the wild.
What claims should I check during a security review?
Start with the four registered claims: iss (issuer — pin it, do not trust any value), aud (audience — pin it to your service's identifier), exp (expiry — enforce, with sub-second clock skew tolerance only), and nbf (not-before — reject tokens from the future). Then check sub (subject) and jti (JWT ID) against your session store if you maintain one. Algorithm confusion (RS256 token re-signed with public key as HS256 secret) is the other classic find — your verifier must pin the expected algorithm.
Is my JWT logged or transmitted by this tool?
No. The page contains no fetch() to any analytics or third-party origin in the JWT handling code path. Decoding is purely string manipulation: split on dots, base64url-decode each segment, JSON.parse the result. You can verify by opening the DevTools Network tab while you paste a token — there will be zero traffic. If you are still nervous, save the page locally and open it as a file:// — it will work identically.