What JWTs are used for
JSON Web Tokens carry signed claims between services — commonly for authentication (who is this user?), authorization (what can they do?), and session state in OAuth 2.0 and OpenID Connect flows. A JWT has three Base64url-encoded parts: header, payload, and signature.
Typical developer workflows
- Decode — inspect claims like
sub,exp, andaudwhen debugging 401/403 errors - Validate — verify HMAC or RSA signatures with your secret or public key
- Generate — create test tokens for local API development
- Edit claims — modify payload fields and re-sign for integration testing
Security essentials
JWT payloads are only Base64url-encoded — not encrypted. Anyone with the token can read the claims. Never store secrets in JWT payloads unless you use JWE (encrypted JWTs). Always validate signatures server-side; client-side validation is for debugging only. Check exp (expiration) and nbf (not before) claims to prevent replay attacks.
Algorithm confusion
A common vulnerability is accepting alg: none or switching RS256 to HS256. Your API must explicitly allowlist accepted algorithms and reject tokens with unexpected alg header values. Use the validator tool to confirm which algorithm a token uses before trusting it.
Frequently asked questions
Is it safe to paste production JWTs into an online tool?
These tools run entirely in your browser — tokens are not sent to any server. However, treat production tokens like passwords: avoid sharing them in screenshots or screen shares, and rotate them if accidentally exposed.
What is the difference between JWT decode and validate?
Decoding reads the header and payload without checking the signature. Validation verifies the cryptographic signature using your secret or public key — required before trusting the claims.
Why does my token show "expired"?
The exp claim is a Unix timestamp. If the current time is past exp, the token is no longer valid. Generate a new token with a future expiration for testing.