JWT Signature Verifier

Actually verify a JWT signature in your browser with a key you supply, and get a plain verified or not-verified answer instead of a decoded payload that proves nothing.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Token

Algorithm to verify with Pre-filled from the token's header for convenience, but this is the value that gets used - never the token's own. That is the point.

Public key (JWK or PEM)

The algorithm comes from you, not from the token

This is the single design decision that matters here, and it is the one most JWT libraries got wrong for years. If a verifier reads alg out of the token and uses it, the token gets to choose how it is checked - and an attacker will choose something that passes.

Two attacks come directly out of that. alg: none declares that there is no signature, and a verifier that obeys accepts a payload anyone can write. Algorithm confusion is subtler: take a service that verifies RS256, re-sign the token as HS256 using the RSA public key as the HMAC secret, and a verifier that trusts the header will use that same public key - which the attacker also has - and confirm the forgery.

So the picker above is filled in from the header as a convenience, and then ignored in favour of whatever it actually says. If the two disagree, the result tells you. Your own verifier should be configured the same way: one algorithm, fixed, never read from input.

What a pass means, and what it does not

A verified signature means exactly one thing: this token was signed by whoever holds the key you supplied, and nothing in it has changed since. It does not mean the token is currently valid. Expiry, audience, issuer and revocation are all separate checks, and a signature check that people read as "the token is fine" is how expired tokens get accepted.

A failure, conversely, usually is not an attack. The common causes are the wrong key, the right key in the wrong format, or the wrong encoding selected for an HMAC secret. Rule those out before concluding anything dramatic.

Formats it accepts

JWK - a single public key object. A JWKS is rejected with a note to pick one key, since verifying against "one of these" is not a meaningful answer.
PEM - a PUBLIC KEY block (SubjectPublicKeyInfo).
Shared secrets for the HS algorithms, as plain text, base64url or hex.

Private keys and certificates are refused with an explanation rather than a generic error. Verification never needs a private key, and a page that accepts one is teaching a habit worth not having.

Everything runs in your browser

Verification uses the Web Crypto API built into the browser. The token, the key and the result stay on your machine - no request is made, which matters because the two things being pasted here are a credential and a key.

Frequently asked questions

My secret is definitely right, but it says not verified.

Check the encoding selector. A secret shown as base64 in a config file is bytes, not the literal characters - verifying it as UTF-8 text uses the wrong key entirely. That accounts for most of these.

Why won't it accept my JWKS?

Because "verified against one of these five keys" is not an answer you can act on. Use the JWK and JWKS Viewer to find the key matching the token's kid, then paste that one.

It says my ES256 signature verified, but another tool disagrees.

ECDSA signatures come in two encodings: the raw r||s pair that JOSE specifies, and the DER sequence OpenSSL emits. This page accepts both and converts as needed. A tool that only handles one will report a valid signature as forged.

Can I verify with a private key?

No, and you do not need to. The public half verifies. Pasting a private key into any web page is a habit worth avoiding, so this one refuses rather than quietly accepting it.

Is anything uploaded?

No. Web Crypto runs in the browser; no request is made with the token or the key.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.