JWT Structure Viewer
A JWT anatomy viewer with automated security red-flag detection (alg:none, kid injection risk, signature-length mismatches) and side-by-side alg:none / alg-confusion tampering demos -- structure only, no verification.
What this tool does
Splits a JWT into its three segments, decodes the header and
payload, and runs an automated static scan for the specific
structural red flags that show up in real JWT vulnerabilities --
alg: none, algorithm-confusion risk, missing
expiry, and header fields with a history of injection attacks.
This is a focused, structure-only companion to this site's
general JWT Decoder & Generator
(which verifies and signs tokens with a real key) -- here for
reading a token's anatomy and spotting what's suspicious about
it, never for checking whether its signature is actually
valid.
alg: none -- the classic bypass
The JWT spec allows an alg of none,
meaning "this token is intentionally unsigned." Some JWT
libraries, historically, honored whatever alg a
token's own header claimed -- which meant an attacker could take
a legitimate token, change its payload (e.g. to
"role":"admin"), set the header to
{"alg":"none"}, drop the signature entirely, and
have it accepted as valid. The fix is always on the verifier's
side: a correctly configured library pins the expected
algorithm itself and rejects anything else, rather than trusting
the token to say what algorithm was used to protect it. The
Attack Demos tab on this page builds exactly this kind of
tampered token from whatever you paste in, purely to show the
shape of the attack.
RS256 / HS256 algorithm confusion
A related, subtler bug: if a server is configured to accept
either RS256 (asymmetric, verified with a public key) or HS256
(symmetric, verified with a shared secret) depending on the
token's own alg header, an attacker who knows the
server's RSA public key -- which is, by design,
not secret -- can sign a forged token with HS256 using that
public key string as the HMAC secret. If the server naively
feeds the same "verification key" into whichever algorithm the
token claims, it will validate the forgery. This was documented
as far back as 2015 and keeps resurfacing in real CVEs,
including library-level variants that confuse RSA and HMAC keys
even without attacker-supplied algorithm switching. The fix,
again, lives entirely on the server: never let the token choose
its own verification algorithm.
Why kid (and similar) header fields deserve scrutiny
The optional kid (Key ID) header field tells a
verifier which key to use -- and in several real-world
vulnerabilities, applications used an attacker-controlled
kid value directly in a file path or database
query without sanitizing it, enabling path traversal or SQL
injection to smuggle in a key the attacker chose. This tool
flags the mere presence of kid, jku,
and x5u as worth a second look in server-side code,
not as proof of a vulnerability by itself.
Security scan, not a security verdict
Every check here is a structural, static read of what the
token's own header and payload claim -- it cannot tell you
whether a signature is cryptographically valid, because
validity depends on a secret or key this tool is never given.
A token can pass every check here and still be a forgery if the
server accepting it is misconfigured, and a token can fail a
check here (like a missing exp) and still be
exactly what a particular system intends.
Privacy
Everything runs entirely in your browser. Nothing you paste here is sent anywhere.