Paste a JSON Web Token to decode its header and payload, then read a graded security report. It flags the alg none trap, key confusion risk, missing or expired expiry, secrets sitting in plain sight in the payload, and external key references an attacker can abuse.
A JSON Web Token looks like one long opaque string, but it is just three base64url chunks joined by dots: a header, a payload, and a signature. The header and payload are encoded, not encrypted, so they are readable by anyone who holds the token. This tool decodes both, then audits the parts that decide whether the token is safe, drawing on the token handling guidance in the JWT Best Current Practices and the core RFC 7519.
The header names the algorithm used to sign the token. The classic failure is a token that sets the algorithm to none, which means it carries no signature at all. A server that trusts that header will accept a payload an attacker wrote by hand. The inspector flags a none algorithm as a critical finding and explains the fix, which is to pin the expected algorithm on the server and reject anything else.
When a token uses an HMAC algorithm like HS256, the same secret both signs and verifies it, so anyone who can verify can also forge. There is a sharper version of this: if a service expects an asymmetric algorithm like RS256 but a library lets the attacker switch the header to HS256, the attacker can sign a forged token using the service public key as the HMAC secret. The public key is not a secret, so the forgery passes. The tool notes when a token uses a symmetric algorithm so you can confirm the verifier pins the algorithm it expects.
A token with no exp claim never expires, so a single leaked token is valid forever. The inspector flags a missing expiry, tells you when a token has already expired, and warns when the gap between issued at and expiry is very long, since a long lived bearer token is a long lived liability if it leaks.
Because the payload is only encoded, putting a password, an API key, or sensitive personal data inside it is the same as publishing it to anyone who sees the token. The tool scans claim names and values for the patterns that should never travel in a JWT and points them out. This is the same readable by anyone surface that makes cookie and token handling worth getting right.
The header can carry a jku or x5u field that points the verifier at a URL to fetch the key from. If the verifier follows that URL without a strict allow list, an attacker points it at a key they control and forges valid tokens, often pulling the server into a request to an internal address along the way. A kid field is meant to be an opaque key id, but if the server feeds it into a file path or a database query it becomes an injection sink. The inspector surfaces these so you can check how the verifier treats them.
Each graded check contributes a weighted share of a score out of one hundred. A pass earns its full weight, a weak setting earns part of it, and a dangerous one earns none. The grade is a fast signal about the token as it stands, not a verdict on the whole system. This tool decodes and audits, it does not verify the signature, because verifying needs the key and the key never belongs in a page like this. Judging whether a token is actually safe means understanding how the server issues and checks it, which is the kind of context an AI security testing approach reasons about rather than pattern matching one string. For the wider set of token and session boundaries attackers probe, see the access control writing.