Verify compact HS256, HS384, or HS512 JWT signatures with a literal UTF-8 shared secret and report structural, exp, nbf, and iat status locally. Essential for developers testing HMAC-based token verification, debugging signature mismatches, and validating token integrity without a server.
JWT tools
JWT Token
Drag & drop supported
Verification result
Paste a JWT token on the left.
This verifier checks HMAC integrity for HS256/384/512 plus basic NumericDate status; it does not validate RSA/ECDSA keys, issuer, audience, nonce, or authorization.
Follow this implementation-specific workflow for HMAC JWT Signature and Lifetime Verifier; each step reflects the controls and limits in the current browser workspace.
Step 1
Paste or import the exact compact three-segment token; preserve its original header.payload bytes.
Step 2
Confirm the header alg is HS256, HS384, or HS512 and enter the exact shared secret as literal text, not Base64 or hexadecimal unless those characters are the real key.
Step 3
Keep Live enabled or press Validate to invoke Web Crypto verification over the original signing input.
Step 4
Review structure, algorithm, signature verdict, expiration/not-before errors, and future-issued-at warning independently.
Step 5
Before accepting the token, enforce expected algorithm, issuer, audience, nonce, clock-skew, and authorization rules in the actual application.
Consequence: The verifier UTF-8-encodes the characters exactly, so a key represented in Base64 or hex will not match its decoded bytes.
Fix: Enter the same literal secret used by the issuer, or use a verifier that explicitly imports the issuer’s key representation.
Consequence: Structure can be valid while the secret is missing, the algorithm unsupported, or the HMAC mismatched.
Fix: Require an explicit Signature: Valid result and independently review every error and warning.
Consequence: Asymmetric algorithms need the correct public key and algorithm import; this implementation supports only HMAC SHA-2 variants.
Fix: Use a maintained JOSE verifier with trusted JWK/JWKS handling and strict issuer/audience/algorithm policy.
Inspect the alg and claims, verify the unchanged compact signature with the exact shared secret, then enforce application-specific issuer and audience policy.
The sample signature is HMAC-SHA-256 over the first two compact segments with UTF-8 key “your-256-bit-secret”; it contains no exp claim.
Only HS256, HS384, and HS512. Other alg values retain a valid structural parse but return Signature: Not checked with a warning.
Not by itself. The API must also trust the key and issuer, require the expected audience and algorithm, check lifetime/nonce, and authorize the subject and scopes.
TextEncoder converts exactly what you type to UTF-8 bytes; no Base64, hex, JWK, or passphrase derivation step occurs.
Signature integrity and lifetime are independent. Numeric exp at or before the browser’s current Unix second adds an expiration error even when HMAC succeeds.
No. The report contains only structure, algorithm, and signature status lines, but the secret remains in the input field and page memory until cleared or closed.
The token and typed shared secret are used only in browser memory by Web Crypto and are not uploaded or written to the downloaded verdict. Verification can work offline after assets are cached; clear both fields and any clipboard history when finished.
