DEVELOPER TOOL

JWT / JWS Signature Verifier

Verify compact JWT/JWS signatures locally with an explicit algorithm and supplied public key or secret.

Runs locallyRuns locally in your browser. Your data is not uploaded.

Tokens, keys and secrets stay in this browser. Supply a public key for asymmetric verification. Never paste a private key. A valid signature does not establish claims validity, issuer trust or authorization.

JWT / JWS signature verification

Signed token

Verification key

Minimum 256/384/512 secret bits for HS256/384/512. No asymmetric key reuse. Samples are public demonstrations.

Ready.

Verification report

The token algorithm must match your selection. Embedded key hints, jku, x5u and remote JWKS URLs are never retrieved or trusted. Signature verification is not a complete JWT validation or authentication policy.

Verify a signature against the key you supply.

Select the expected algorithm independently of the token. The header must match that selection. HS256/384/512 require an explicit high-entropy secret of at least the hash output length. RS256/384/512 and PS256/384/512 use RSA keys of 2,048–8,192 bits; PSS uses a salt equal to the hash output length. ES256 and ES384 use P-256 and P-384 with the compact JWS raw R/S signature format. No automatic algorithm fallback occurs. Unsigned alg:none tokens are never verified.

Use public keys and unambiguous JWKS entries.

Use PEM PUBLIC KEY (SPKI) or a public JWK for asymmetric algorithms. Pasted JWKS contains at most 16 keys. A token kid must select exactly one key; duplicate or missing matches fail. Without kid, only a single-key set is accepted. Key type, curve, declared alg, use and key_ops must be compatible. Private JWK parameters are identified without displaying their values and refused for verification. Embedded keys and remote key hints are ignored. There is no JWKS retrieval or issuer discovery.

Signature validity is separate from claims.

A valid signature only establishes a match to the supplied key. It does not prove issuer trust, audience suitability, current validity or authorization. Separate exp, nbf and iat findings use browser time at verification, with no clock tolerance. Optional issuer and audience checks use exact equality or audience-array membership. A trusted application must apply its complete validation policy independently.

Formats, limits and privacy.

Compact tokens are limited to 8 KiB and must contain strict UTF-8 JSON header/payload objects with unique names and at most 16 nesting levels. Base64URL must be canonical and unpadded. JWE, detached/unencoded payloads, critical extensions, ES512 and EdDSA are outside this initial implementation. Public keys/JWKS are limited to 32 KiB; encoded HMAC secrets to 4,096 characters. Common PEM/JSON/DER key encodings are refused as HMAC secrets. Public metadata is shown; secrets are masked initially. Reset and page exit clear local state. Native crypto cannot be interrupted, but stale results are discarded. No key or token enters storage, URLs, logs or tool analytics. Explicit copying writes the report to your clipboard.

Find a tool or category

Tools & categories12 results