Inspect a JWT and verify its signature with an HMAC secret or a public JWK or JWKS. Add an expected issuer or audience to check those claims as well; decoding a token by itself does not verify its authenticity.
Runs locally in your browserFor HS256/384/512, enter the raw shared secret. For asymmetric algorithms, paste a public JWK or JWKS JSON document.
Decode or verify a compact JWT to inspect its protected header and payload.
Anyone can decode a JWT payload. Treat a token as trusted only after a successful signature check with the intended algorithm and key, plus issuer, audience, time, and application-level claim validation.
Paste a compact JWT and the tool shows its protected header and payload, then verifies the signature with the key material you supply: a raw shared secret for HS256/384/512, or a public JWK or JWKS document for RS, PS, ES and EdDSA. An expected issuer or audience can be checked in the same run.
Decoding is not verification. The page decodes locally and says so, and it only reports a token as verified after the signature and the registered claims (exp, nbf, iss, aud) pass. Nothing is uploaded, no JWKS URL is fetched, and the key material is not stored.
Inspect token runs the payload through a JWT decoder and prints the protected header and the payload as JSON. The status line stays a warning on purpose: anyone who holds the token can read it, so decoded claims are only a preview of what the token claims to be.
A token that declares no signed algorithm (alg none or missing) still decodes here, because inspection never requires a signature. Verify signature is the check that refuses it.
With a shared secret, the signature is recomputed over the exact token text and compared; with a public key, the corresponding JWK is imported and used. A JWKS document is searched for the key whose kid matches the token header, falling back to the first key when the token carries no kid.
The registered claims are checked in the same run: exp and nbf against the current clock, iss against the expected issuer and aud against the expected audience when those fields are filled in. The status line names the first failure — signature verification failed, an exp or nbf timestamp check, an unexpected or missing iss or aud value — instead of a generic error.
The overview lists Algorithm, Key ID, Issuer, Audience, Subject and Expires; an audience array is printed as a comma-separated list. The panel underneath is the decoded token as pretty-printed JSON, with protectedHeader and payload in one document.
Both panels are read-only text: the result can be selected and copied, and a verified run keeps the same layout as an inspection, so nothing hides the fact that the signature is the part that makes the claims trustworthy.
Everything happens in the tab with the jose library and the Web Crypto API. The page makes no request while inspecting or verifying, it never fetches a JWKS URL — you paste the document — and the key material stays in the form fields.
The example button is the only place a private key exists, and it never leaves the page: the key pair is generated in the browser, the token is signed there, and the field is filled with the public JWK only. That also means key rotation is manual here: a rotated JWKS has to be pasted again.