JWT Security Checker — Detect JWT Vulnerabilities
Decode · Inspect · Verify · Generate JSON Web Tokens — expiry countdown, security warnings, HS256 verify — 100% browser-side
JWT security vulnerabilities have caused major breaches — from the alg:none attack (CVE-2015-9235) to algorithm confusion attacks. This security checker automatically scans your JWT for the most common vulnerabilities: insecure algorithms, missing expiry, expired tokens, and weak algorithm choices. Every issue is flagged with a severity level (critical/warning/info) and a clear explanation of the risk and recommended fix.
What is a JWT Decoder?
A JWT Decoder reads a JSON Web Token and displays its three parts in human-readable format. Every JWT contains a Header (algorithm & type), a Payload (claims — user data, expiry, issuer), and a Signature. This tool decodes all three instantly, shows expiry status with a live countdown timer, highlights standard claims with labels, detects security issues like alg:none, and supports HS256/HS384/HS512 signature verification using the browser Web Crypto API.
JWT Structure — How It Works
A JWT looks like xxxxx.yyyyy.zzzzz — three Base64URL-encoded strings joined by dots. The header and payload are readable by anyone; the signature is what proves authenticity. Only the party holding the secret or public key can verify the signature. This means JWTs should never contain sensitive data like passwords.
Frequently Asked Questions
What is the alg:none JWT vulnerability?
CVE-2015-9235: Setting alg to "none" tells vulnerable libraries to skip signature verification entirely — any payload is accepted as valid. An attacker can modify the payload to claim any identity. Fix: always whitelist specific algorithms (e.g., only allow RS256) and reject any token where alg is "none" or unexpected.
What is an algorithm confusion attack on JWT?
If a server accepts both RS256 (asymmetric) and HS256 (symmetric), an attacker can take the server's public key (which is public!) and sign a token with it using HS256. A vulnerable library might verify this as a valid HS256 token. Fix: hardcode the expected algorithm in your verification code — never read it from the token header.
Is it safe to store JWTs in localStorage?
localStorage is accessible by any JavaScript on the page — making it vulnerable to XSS attacks. If an attacker can run JS on your page, they can steal all JWTs from localStorage. Safer alternative: use HttpOnly cookies (inaccessible to JS). If you must use localStorage, ensure strict Content Security Policy (CSP) to prevent XSS.
What are JWT security best practices?
1. Always validate the signature server-side. 2. Check exp on every request. 3. Whitelist algorithms (never accept alg:none). 4. Use short expiry (15 min for access tokens). 5. Use HTTPS only. 6. Store in HttpOnly cookies when possible. 7. Implement refresh token rotation. 8. Add jti for single-use tokens. 9. Validate iss and aud claims.
How do I revoke a JWT before it expires?
JWTs are stateless — the server can't revoke them without a blocklist. Options: (1) JWT blocklist: store revoked jti values in Redis, check on every request. (2) Short expiry: use 5-15 minute tokens — compromise window is small. (3) Token versioning: add a "tokenVersion" claim, increment in DB on logout — verify version matches DB. (4) Opaque tokens: use a random string, look up in DB (not stateless but fully revocable).