Verify JWT signatures with HMAC, RSA, or ECDSA keys. Check expiration, issuer, audience, and custom claim validation.
JWT Signature Verifier checks whether a compact JWT's signature is valid for a supplied HMAC secret, RSA public key, or elliptic-curve public key. It can also evaluate expiration, issuer, audience, and configured custom claims. The important distinction is that readable header and payload data are only decoded, not trusted. Authenticity requires a successful signature check, while acceptance also requires the right claim rules and a trusted key. Verification stays in the browser, so the token and key are not uploaded.
For a compact signed JWT, the verifier separates the three dot-delimited segments. The first two encoded segments, including the dot between them, form the JWS signing input. It decodes the signature segment and checks it with the supplied HMAC secret or RSA or elliptic-curve public key. Changing even one header or payload byte causes signature verification to fail.
The verifier parses the payload as a JWT claim set and applies the requested checks. Expiration is evaluated from the exp NumericDate, which counts seconds from the Unix epoch. Issuer and audience checks compare iss and aud against expected values, while custom validation examines configured claims. Signature and claim results are separate: a correctly signed token can still fail an expiration or audience check.
Use the corresponding public key for RSA or ECDSA verification. The private key is required to create signatures, not to prove them, so exposing it to a verifier is unnecessary. HMAC is different: verification requires the same shared secret used for signing because HMAC has no separate public verification key.
No. A valid signature establishes that the compact header and payload match the signature under the supplied key. Acceptance also requires trusting that key for the claimed issuer, permitting the declared algorithm, checking applicable time constraints, matching the intended audience, and enforcing application-specific authorization. The verifier cannot determine those trust and permission decisions by itself.
The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.