JWT Security Checker
Check a JSON Web Token for the configuration mistakes that make tokens forgeable — alg confusion, missing expiry, leaked data.
Runs entirely in your browser. Nothing you paste is uploaded, logged, or stored.
What this checker looks for and why it matters
Paste a JWT and this tool decodes it in your browser, then runs the header and payload through the same class of checks a real attacker would try first. A JWT's security does not live in the token itself — it lives in how strictly the code that verifies it is written — but a token can still leak a lot about how forgeable it is and how much damage a copy of it could do if it leaked. That is what this report grades.
Algorithm confusion and "alg": none
The single most damaging JWT bug is accepting "alg": "none". The JWT spec allows an unsigned token as a legitimate (if unusual) option, and several early JWT libraries verified tokens by checking whatever algorithm the token itself claimed to use. That means an attacker can take any valid token, edit the payload to grant themselves more access, set alg to none, delete the signature entirely, and a vulnerable verifier accepts it as authentic. This tool treats an alg: none token as a critical finding, full stop.
A subtler variant is RS256/HS256 confusion. When a service is designed to verify with an asymmetric algorithm (RS256, where only the server holds the private signing key), but the verification code also accepts HS256, an attacker can exploit the fact that RSA public keys are, by design, not secret. They fetch the public key — often published at a well-known JWKS endpoint — and use it as the shared secret to sign a forged HS256 token. A verifier that trusts the alg the token claims, rather than enforcing the algorithm it expects, accepts the forgery. This tool cannot know whether a given token is meant to be asymmetric, so it surfaces HS256 tokens as an informational finding explaining the risk rather than assuming the worst.
Missing or excessive expiry
A JWT with no exp claim is valid indefinitely. Combined with the fact that most systems cannot revoke a single JWT without extra infrastructure — a denylist keyed on jti, most commonly — a leaked token with no expiry is a standing credential with no kill switch. This tool flags a missing exp as high severity, and also checks the gap between iat and exp: over 24 hours is flagged as medium, and over 30 days as high, because access tokens are meant to be short-lived by design.
Sensitive data sitting in the payload
A JWT payload is base64url-encoded, not encrypted. Decoding it is a one-line operation with no key required — this tool does exactly that to show you the claims, and so can anyone who intercepts the token, reads a log line it ended up in, or opens their browser's dev tools. This check scans every claim name and string value for patterns that should never be there: password, secret, api_key, private_key, ssn, card numbers, and nested tokens. It also flags plain email addresses separately — not a secret exactly, but PII that ends up far more widely distributed than intended once it is riding inside a token that gets logged on every request.
kid, jku and x5u header injection
Three header fields exist to tell a verifier which key to use, and all three have been the root cause of real-world JWT vulnerabilities because implementations trusted them too literally:
kid(Key ID) is often used to build a file path, a database lookup, or a cache key. Unsanitised, it enables path traversal (../../dev/null) or SQL injection into the key-lookup query.jkuandx5upoint the verifier at a URL to fetch the signing key (or certificate) from directly. Without a strict allow-list of trusted hosts, an attacker supplies their own key server, signs a token against their own key, and the verifier dutifully fetches and trusts it.
This tool flags a kid value containing path traversal sequences, SQL metacharacters, or an embedded URL, and flags jku/x5u whenever they are present at all — they are legitimate but need to be handled very carefully server-side.
The rest: iss, aud, jti and hygiene checks
Missing iss and aud claims are lower severity individually, but together they are what makes token confusion possible — service B accepting a token that was only ever meant for service A, because neither side checked who issued it or who it was addressed to. A missing jti just means you cannot revoke this one token individually later; harmless if you never need to, a gap if you do.
{
"iss": "https://auth.example.com",
"aud": "https://api.example.com",
"sub": "user_44802",
"iat": 1758000000,
"exp": 1758003600,
"jti": "b021cfd0-67f1-49d6-ad0c-97d05f4b3691"
}How the grade is calculated
Every report starts at 100 and deducts per finding — more for a critical issue like alg: none than for a low-severity gap like a missing jti. The result is the same A-F scale used across every Averto tool, so a grade means the same thing here as it does on the security headers checker. Read the individual findings regardless of the letter grade: one critical finding on an otherwise clean token matters more than five low-severity ones.
Frequently asked questions
What does this JWT security checker actually look for?
It decodes the token in your browser and inspects the header and payload for known-risky patterns: an unsigned "alg": "none" token, algorithm confusion risk, missing or excessive expiry, sensitive data sitting in the payload, and header fields like "kid", "jku" or "x5u" that are common injection points.
Can this tool verify whether my token is genuine?
No. Verifying a signature requires the issuer’s private or shared key, which this tool never has and never will ask for. It reports on the token’s structure and configuration — the things that make a token forgeable or risky regardless of whether this particular copy is genuine.
Is it safe to paste a real production token here?
Yes — this check runs entirely client-side. There is no fetch() call in this tool, no analytics event fires on the token, and nothing is written to a server or a log. You can verify this yourself with your browser’s network tab: pasting a token generates zero network requests.
What is "alg" confusion, in plain terms?
It is an attack against JWT libraries that trust the algorithm named inside the token rather than the one the server expects. If a service normally verifies tokens with a public/private key pair (RS256) but naively also accepts HS256, an attacker who knows the public key can sign a forged HS256 token using that public key as the shared secret — and a vulnerable verifier accepts it as legitimate.
Why does a missing expiry matter so much?
A JWT without an "exp" claim is valid forever once issued. If it is ever stolen — through a logging mistake, a compromised device, or a leaked request — there is no automatic point at which it stops working, unless the issuer has built separate revocation infrastructure most systems do not have.
My report flagged an email address or a token-shaped claim. Is that really a problem?
It is worth a second look. JWT payloads are base64url-encoded, not encrypted, so anything in them is readable by anyone holding the token — and tokens routinely end up in browser storage, proxy logs and error trackers. PII and secondary secrets inside a JWT get exposed far more widely than the same data would be sitting in a database.
What is kid injection?
The "kid" header tells a verifier which signing key to use, and some implementations build a file path, database query or URL directly from it. An attacker who controls the "kid" value can potentially point the verifier at a file, table entry or URL of their choosing — this tool flags "kid" values containing path traversal, SQL metacharacters or an embedded URL.