How to Inspect JWT Signatures
JWT Signature Inspection
What Signature Inspection Checks
This tool checks whether the cryptographic signature matches your HMAC secret or RSA public key, then decodes claims and time-based fields — all locally in your browser for debugging. Signature matching is reported separately from expiration (exp) and not-before (nbf). A matching signature does not by itself mean the token is currently usable.
HMAC vs RSA
HS256/384/512 tokens require the shared secret used at signing time. RS256/384/512 tokens require the issuer's public key in PEM format. The algorithm in the JWT header must match the key type you provide. ECDSA (ES256/384/512), PS256, and EdDSA are not supported.
Common Mistakes
- Using the wrong secret or public key for the token issuer
- Trusting validation alone without checking
audandissclaims in production - Pasting a malformed PEM key missing BEGIN/END lines
Developer Tips
- Decode first with the JWT Decoder to inspect claims before checking signatures
- Paste a JWKS document (RS*) into JWT Signature Checker settings — remote JWKS URL fetch is not supported
- Check clock skew if tokens appear expired immediately after generation
Frequently asked questions
Does this check against a remote JWKS endpoint?
No. Paste an HMAC secret, RSA public key (PEM), or a JWKS JSON document locally. No JWKS URL is fetched and no network requests are made for keys.
What PEM format is supported for RSA?
Standard SPKI public keys: -----BEGIN PUBLIC KEY----- blocks.
Does inspection mean the token is authorized and currently usable?
Inspection confirms whether the signature matches your key. Check exp and nbf separately — a token can have a matching signature but be expired or not yet active. Authorization still requires checking roles, scopes, and audience claims in your application.