Loading JWT Security Inspector…
No signature is checked here, and none can be. That takes the key the token was signed with, which lives with the issuer and its verifier and not in a web page. So every line below is a report on what this token SAYS about itself, and an attacker writes those bytes as freely as the issuer does. A clean report is not a valid token; a valid token is not a safe one.
Nothing to review yet. Paste a token and every header and claim is checked against the practices in RFC 8725.
The one check worth running yourself is the one no tool can run for you: hand the token to the service that issued it with a single character of the payload changed, and confirm it is refused. A service that accepts it is not verifying the signature at all, and no amount of careful claims will save it.
A token is a live credential for as long as it is valid. Nothing on this page is sent anywhere — the review happens in your browser and no request is made — but the habit of pasting production tokens into web pages is worth breaking, because most tools that look like this one do post them to a server.
This page judges a token rather than reading one out. It walks the JOSE header and every claim, compares what it finds against the practices in RFC 8725, and returns a ranked list of weaknesses: an algorithm that lets the token choose how it is checked, an expiry that is missing or years away, a key source the sender controls, material in the payload that should never have travelled in one.
It does not verify the signature, and it cannot: that takes the key — a shared secret, or the issuer’s public half — and a page running on your machine holds neither. The distinction is worth being blunt about. Every finding below is therefore a statement about bytes an attacker can write as freely as the issuer can. An empty findings list means the token is well shaped, and nothing more than that.
Four header parameters from RFC 7515 hand control of verification to whoever wrote the token. A jwk carries a key inline, so trusting it means checking a signature against a key the sender supplied — which every forgery will pass. A jku or x5u names a URL to fetch a key from, turning the token into an instruction to trust a host an attacker may own, and into an outbound request made on their behalf.
The value alg deserves the same suspicion. Setting it to none is legal, means the token carries no signature at all, and is refused here at the top severity. A switch from RS256 to HS256 is subtler: the verifier is handed the issuer’s public key as though it were a shared HMAC secret, and a library that reads the algorithm from the header will happily accept the result. Both attacks end the same way — the algorithm must come from your configuration, never from the token.
A token is useful to a thief for exactly as long as it remains valid. The three lifetime bands used here are this tool’s own thresholds rather than a standard’s: RFC 9700 asks for short-lived access tokens without naming a figure, and RFC 6749 uses 3,600 seconds in its own example, so anything past an hour is noted, past a day is flagged, and past three months is treated as severe.
Two other absences shape how far a copy travels. Without aud, no service can tell that a token minted for one API was not meant for it, and RFC 7519 says a recipient not named there is supposed to refuse it. Without jti, a replayed token is indistinguishable from a first use and a single credential cannot be revoked on its own.
The payload is encoded, not encrypted: anyone holding the token reads it without a key, including every proxy, log aggregator and browser extension it passes on the way. So the inspector walks nested claims looking for names that suggest a password, an API key, another token, a card number or a one-time code, and reports each with its path.
Personal data is reported separately because the problem is different in kind. An email address or a date of birth in a token is not forgeable, it is simply disclosed, everywhere the token goes and for as long as anyone keeps a copy. A subject identifier the issuer can resolve carries the same meaning with none of that exposure.
No. The findings cover shape and content only. The token may still be forged, replayed, or signed by somebody other than the issuer it names, and only a verifier holding the right key can rule any of that out.
They are chosen here, not quoted from a specification. The relevant standards ask for short-lived tokens without giving numbers, so the bands are round figures picked to start a conversation about how long a stolen copy stays useful.
It is noted rather than faulted. Symmetric signing means every service that can check a token can also mint one, and it is the algorithm the confusion attack targets, so it is worth knowing which family you are in.
Rotate it, then work out how many copies exist. That claim has been in every log line, error report and analytics event that ever recorded the token, so treat the value as public from the moment it was first issued.
Because a finding you cannot see the evidence for is hard to act on. The two panels exist so a flagged claim can be located in context, not to replace a tool built for reading tokens end to end.