JWT signature verification explained (HS256 vs RS256)

A JWT is easy to decode, but decoding does not prove it’s trustworthy. Signature verification answers the question: “Was this token created by someone who has the key, and was it modified?”

What verification checks

The token has 3 parts: header.payload.signature
The signature matches the header+payload when recomputed with the expected key
The algorithm in the header matches what your server expects (don’t accept unexpected algs)

HS256 vs RS256 (in plain English)

Algorithm	Key type	Typical use
`HS256`	Shared secret (same key signs and verifies)	Single service or tightly controlled systems
`RS256`	Public/private key pair	Distributed verification (many verifiers)

Common mistakes that break verification

Using the wrong key (e.g., mixing environments or wrong JWKS)
Verifying with the wrong algorithm (expecting RS256 but token is HS256)
Forgetting that JWT segments are Base64url (not Base64)
Clock skew issues: token can verify but still be invalid due to exp/nbf

Safe debugging tips

Don’t paste production tokens into random websites. Use tools you trust.
Never share secret keys publicly. For HS256, the secret must remain private.
Prefer verifying in your backend code for anything security-critical.

Try it instantly

You can decode a token and inspect its header/payload locally: JWT Decoder.

JWT claims explained (what exp/iat/aud mean)
Base64url vs Base64 (JWT encoding details)
All tools