JWT Parser & Debugger

How JWTs work (and where they go wrong)

A JSON Web Token (RFC 7519) is three base64url-encoded segments joined with dots: header.payload.signature. The header declares the signing algorithm, the payload carries the claims, and the signature proves the token was issued by someone who holds the signing key.

Decoding a JWT is trivial — it is not encryption, it is encoding. Anyone with the token can read the payload. Do not put secrets, PII beyond what you need, or passwords in the claims. Short-lived tokens + refresh rotation + server-side validation is the baseline.

Common JWT vulnerabilities this tool highlights

• alg: none downgrade: some buggy libraries will accept a token signed with none as valid. Attackers strip the signature, change the payload, and the server trusts it. If you see alg: none, the token is unauthenticated — reject it.
• Weak symmetric keys: HS256 tokens signed with short or guessable secrets fall to offline brute force. Use keys with at least 256 bits of entropy. For public APIs, prefer asymmetric signing (RS256, ES256, EdDSA).
• Expired tokens: the exp claim is in Unix seconds. Check every request — do not rely on the client to drop expired tokens.
• Missing aud / iss validation: without audience and issuer checks, a valid token from one service can be replayed against another.
• Algorithm confusion (RS256 → HS256): if the server loads the public key as the HMAC secret, an attacker can sign a forged token with the public key. Pin the algorithm server-side; do not trust the header.
• Sensitive data in claims: remember anyone who obtains the token can decode it. No passwords, no SSNs, no internal hostnames, no secrets.

What the tool does not do

This parser does not verify signatures against a key — doing so would require you to paste your signing key into the page, which we refuse to accept. Signature verification belongs in your server. We decode, structurally validate, and call out the classic footguns.

Continuous JWT scanning at scale

If your codebase has a hundred services and you want to catch "someone hardcoded a JWT secret in a config file" before it ships, you need a continuous scanner. Security Factor 365 includes 81 secret-detection patterns (including JWT secrets, OAuth tokens, and API keys across 20+ vendors) plus SAST rules that catch algorithm: "none" code paths and missing exp validation.