JWT Decoder, Verifier & Generator

Decode any JWT to see its header, payload, and signature. Verify signatures across all common algorithms — HS256, RS256, ES256, EdDSA, PSS, and more. Generate new signed tokens for testing. Scan tokens for the common JWT vulnerabilities (alg:none attacks, weak HMAC secrets, expired claims). Everything runs in your browser via WebCrypto; nothing transmits.

How to use the JWT Decoder

For most use cases, Decode mode is what you want. Paste a JWT — the three Base64URL-encoded segments separated by dots — and the tool splits it into header, payload, and signature, decodes the JSON of the first two, and highlights interesting claims (exp warnings, iss mismatches, missing standard fields).

When you need to confirm a token wasn't tampered with, switch to Verify and paste the secret (for HMAC algorithms) or the issuer's public key in PEM format (for RSA / ECDSA / EdDSA). The result is a clear pass/fail with a reason for any failure: bad signature, expired token, algorithm mismatch, malformed key.

Generate mode is for testing your own verifier. Pick an algorithm, edit the payload JSON, paste a secret, and get a freshly signed token. The example payload uses standard claims (sub, iat, exp) — adjust them or add custom claims as needed.

Vulnerability scan runs four checks: alg:none detection, algorithm confusion detection, weak HMAC secret heuristics, and claim validity. Useful when you're auditing a token issued by a third-party system you don't fully control.

What is a JWT?

A JSON Web Token is a compact, URL-safe way to transmit claims between two parties. The token is three Base64URL-encoded segments separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• Header (first segment): JSON describing the algorithm (alg) and token type (typ), plus optionally a key identifier (kid) and JWK Set URL (jku).
• Payload (second segment): JSON containing the claims. Standard claims are iss (issuer), sub (subject), aud (audience), exp (expiry), nbf (not before), iat (issued at), jti (token ID). Application-specific claims are added freely.
• Signature (third segment): A cryptographic signature over header.payload using the algorithm named in the header. Verifies that the token was issued by someone with access to the signing key and hasn't been tampered with in transit.

The payload is not encrypted — it's Base64URL encoded, which is trivially reversible. Anyone with the token can read its claims. The signature only guarantees authenticity, not confidentiality. For confidentiality, use JWE (JSON Web Encryption) or transport the token over TLS only.

JWT signing algorithms and when to use each

Common JWT vulnerabilities to watch for

Most JWT bugs in the wild fall into one of these four patterns. The vulnerability scanner in this tool checks all of them.

1. The alg:none attack. An attacker forges a token with header {"alg":"none"} and an empty signature. A verifier that trusts the header's algorithm and accepts an empty signature when the algorithm is "none" will accept anything. Fix: verifiers must check the algorithm against an allowlist before verifying, and never accept "none."
2. Algorithm confusion. An attacker takes a public key intended for RS256 verification and uses it as the HMAC secret to sign an HS256 token. A verifier that uses the same library API for both algorithms — passing the key as a generic "secret" — will verify the attacker's token as legitimate. Fix: verifiers must hard-code the expected algorithm, not read it from the header.
3. Weak HMAC secrets. HS256 with a secret shorter than 32 bytes (the digest size) is crackable offline within hours. HS384/512 with shorter-than-digest secrets is the same problem. Fix: HMAC secrets must be cryptographically random and at least as long as the digest output (32/48/64 bytes for HS256/384/512).
4. Expired or future-dated tokens accepted. Verifiers must check exp (expiry), nbf (not before), and clock-skew tolerance. Servers with badly-synced clocks sometimes accept tokens that are minutes expired or hours in the future.