Decode JWT header and payload, see expiration timing, and optionally verify the signature with HMAC (HS256/384/512) or RSA (RS256/384/512) keys. Claim warnings flag expired tokens, future nbf values, and missing aud.
A JWT has three parts separated by dots: header, payload, and signature. The header and payload are base64url-encoded JSON. The signature proves the token wasn't tampered with — verifying it requires the issuing key (a secret for HMAC algorithms like HS256, or a public key for RSA algorithms like RS256).
Header and payload are decoded natively. Signature verification (when a key is pasted) uses the Web Crypto API for HS256/HS384/HS512 (HMAC) and RS256/RS384/RS512 (RSA-PKCS1-v1_5). Pasted tokens and keys never leave the browser. The warning logic walks exp / nbf / iat against Date.now(); PEM parsing for RSA strips headers, base64-decodes, and hands the buffer to importKey with spki.
alg: none — disable in your auth library. Tokens with this algorithm have no signature; old libraries used to accept them silently. Modern libraries reject by default.exp) — verifiers reject expired tokens. Always check exp before use.nbf) — token isn't valid until this time. Useful for delayed-activation tokens.aud (audience) — without an audience claim, your verifier should reject the token to prevent it being replayed against a different service.alg field. Pin the expected algorithm server-side; never derive it from the token itself.kid + JWKS URL, fetch and verify automatically.Canonical references: RFC 7519 (JWT) and RFC 7515 (JWS).