Validate JWT signatures using HMAC secrets or RSA/EC public keys and check claim expiration and audience.
JWT Validator accepts a compact JWT plus verification material: a shared secret for an HMAC-signed token, or a public key for an RSA- or EC-signed token. It verifies whether the signature matches, then evaluates expiration and the intended audience. The common trap is treating a readable header and payload as proof of authenticity. A token can decode cleanly yet fail because its signature, key, secret, expiration, or audience does not match. It does not decrypt claims; signed JWTs are not necessarily encrypted. Browser-only processing keeps the token and sensitive verification material from being uploaded.
A compact JWT normally has three base64url-encoded sections separated by periods. The signed content is the encoded header, a period, and the encoded payload. For HMAC, validation needs the identical shared secret used to create the signature. For RSA or EC, it needs the public key corresponding to the signing private key. Changing either signed section causes verification to fail. Each section uses base64url text without '=' padding.
After verifying the signature, the validator evaluates the claims it supports. An exp value is a NumericDate: a count of seconds from 1970-01-01T00:00:00Z, ignoring leap seconds. The token is expired once that time is reached. Audience checking compares the expected recipient with aud, which can be one case-sensitive string or an array of such strings. A signature can pass even when either claim check fails.
No. Those sections can be decoded without a key, but cryptographic validation requires the token's signature and the matching shared secret or public key. If the header declares alg as "none", the object has no digital signature. It should not be treated as equivalent to a successfully verified signed token. Merely viewing decoded JSON establishes neither integrity nor origin.
They answer different questions. Signature verification checks whether the compact token matches the supplied key or secret. Audience validation checks whether aud identifies the recipient you expected. A token can therefore be authentic but intended for another API. Compare the complete identifier with correct case, including any scheme, path, or other characters that are part of it. Differences that change the string can matter.
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.