Anatomy of a JWT
A JSON Web Token (RFC 7519) is three Base64URL strings joined by dots: header.payload.signature.
The header names the signing algorithm (alg) and often a key ID (kid); the payload carries
the claims; the signature proves the first two parts were not modified.
Registered claims
| Claim | Meaning |
|---|---|
iss | Issuer — who created the token |
sub | Subject — usually the user ID |
aud | Audience — which service should accept it |
exp | Expiration time (Unix seconds) |
nbf | Not valid before (Unix seconds) |
iat | Issued at (Unix seconds) |
jti | Unique token ID, used to prevent replay |
Debugging “invalid signature” errors
- The secret is Base64-encoded in your config but used as plain text (or the opposite) — toggle the checkbox.
- The token was signed with a different key — compare the
kidin the header with your JWKS. - Whitespace or a
Bearerprefix was copied along with the token. - The
algin the header does not match what your library expects.
Frequently asked questions
Is it safe to paste a production JWT here?
Decoding and verification run entirely in your browser using the Web Crypto API; the token and secret are never sent anywhere. Still, treat live tokens like passwords and prefer expired or test tokens when you can.
Does decoding a JWT verify it?
No. The header and payload are only Base64URL-encoded, so anyone can read them. A token is trustworthy only after its signature is verified with the right secret or public key, and its exp/nbf/aud/iss claims are checked.
Which algorithms can be verified?
HS256, HS384 and HS512 with a shared secret; RS256/384/512 and PS256/384/512 with an RSA public key; ES256, ES384 and ES512 with an EC public key. Public keys can be pasted as PEM (-----BEGIN PUBLIC KEY-----) or as a JWK JSON object.
What are exp, iat and nbf?
They are Unix timestamps in seconds: exp is the expiry time, iat is when the token was issued, nbf is the time before which the token must not be accepted. This tool converts them to readable dates in your timezone.