JWT Security Check
Paste a token and get the problems worth knowing about, ranked by severity - from an unsigned alg:none token down to a missing issuer claim. The checks are about the token itself, not the service that issued it.
Output appears here as you type.
Runs entirely in your browser. Nothing you paste here is uploaded or stored.
Questions
Is it safe to paste a real token here?
That is the case this page is built for. Decoding happens in your browser as a pure function, and the page ships a Content-Security-Policy of connect-src ‘none’ - the browser physically refuses to let it open a network connection. Open your network tab, or disconnect entirely: it keeps working.
What is the alg:none attack?
A JWT header names its own algorithm, so a verifier that trusts that field can be handed a token claiming alg:none - meaning unsigned - and accept it. The attacker edits the payload to say whatever they like. The fix is to configure the verifier with the algorithm it expects rather than reading it from the token.
Why does it flag claims like password or api_key?
Because a JWS payload is base64-encoded, not encrypted. Every holder of the token can read it, and tokens end up in logs, browser histories, referrer headers and screenshots. If a value has to stay secret it belongs behind the token, not inside it.
A clean result means the token is secure?
No. These are checks on the token in front of you. They cannot tell you whether the signing key is strong, whether it has leaked, whether the issuer validates anything, or whether the verifier checks the signature at all. Treat a clean result as "nothing obvious", not "safe".