Free Handy Tools

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.

Try an example

Nothing pasted here reaches the address bar. A link to this tool carries only which example is loaded, never the token in this box.

Findings

7 findings, worst critical

Every finding below is about what the token says about itself. None of them is a statement about the signature.

Critical2
High1
Medium2
Low1
Observation1
How this was worked out
  • Segments readheader and payload decoded from base64url; the signature segment is 43 characters, left untouched
  • Signature checkednot at all, and it cannot be — that takes the issuer’s key, which is not in this page
  • Algorithm read“HS256”, taken from the header the sender wrote
  • Lifetime measuredexp − iat = 315,532,800 seconds
  • Claims searchedevery leaf of the payload, four levels deep, against the secret and personal-data name patterns in RFC 8725 §3.11
  • Critical

    Lifetime measured in months

    This token is good for 10.0 years from the moment it was issued. A stolen token is useful for exactly as long as it is valid, and nothing but expiry limits that unless the service keeps a revocation list.

  • Critical

    Secret-looking values in the payload

    The payload is base64, not encryption: anyone holding this token reads every claim in it without a key. These claims look like something that was meant to stay private — user.password (a password). Treat each as disclosed, and rotate it.

  • High

    The header names a URL to fetch a key from

    jku tells the verifier where to get the key. Following it without an allow-list of hosts turns the token into an instruction to trust whatever an attacker can serve, and into a request the server makes on their behalf.

  • Medium

    No aud claim, so nothing limits who may accept it

    The audience says which service the token is for, and RFC 7519 §4.1.3 says a recipient not named there must reject it. Without one, a token handed to one microservice can be replayed against another that trusts the same issuer.

  • Medium

    Personal data travels in the clear

    email (an email address) can be read by every proxy, log and browser extension the token passes, and by anyone it is pasted to. A subject identifier the issuer can resolve carries the same meaning without the disclosure.

  • Low

    No jti, so a replay leaves no trace

    A unique identifier lets a service spot the same token being presented twice and lets a single token be revoked without invalidating every other one. It matters most for one-time tokens: a password reset or a magic link without a jti can be used until it expires.

  • Observation

    Signed with a shared secret

    HS256 is HMAC: the key that verifies this token is the same key that signs it, so every service that checks it can also mint one. It is also the algorithm on the receiving end of the confusion attack — a token switched from RS256 to HS256 and signed with the issuer’s own public key, which a verifier that takes the algorithm from the header will accept.

How the findings are ranked

  • CriticalForgeable or already handing over a secret.
  • HighA real weakness in how the token is meant to be used.
  • MediumWorth changing, or worth knowing before you rely on it.
  • LowA hardening measure that is missing.
  • ObservationNot a fault — a fact about this token.

The severity beside each finding is this tool’s ranking, not a standard one, and it describes the shape of the token rather than your risk: a ten-year lifetime on a token that never leaves one process matters less than a fifteen-minute one pasted into a support ticket. The lifetime thresholds — an hour, a day, ninety days — are round numbers chosen here, because RFC 9700 asks for short-lived access tokens without naming a figure.

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, no request is made, and the token is kept out of the address bar — 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.

A review of the token, not a ruling on it

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.

The header parameters that decide who holds the key

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.

Lifetime, audience, and the cost of one leaked copy

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.

Claims that were never meant to be readable

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.

Questions about inspecting a token

If nothing is flagged, is the token safe to accept?

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.

Where do the lifetime thresholds come from?

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.

Is HS256 a finding on its own?

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.

I found a secret in a payload. Is rotating it enough?

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.

Why show the header and payload at all if this is not a decoder?

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.

Sources

Last reviewed 27 August 2026