What Is a JWT? A Complete Explanation of JSON Web Tokens
Quick Answer
A JWT is a string with three Base64URL-encoded parts separated by dots: header.payload.signature. The header specifies the algorithm, the payload contains claims (user ID, roles, expiration), and the signature proves authenticity. JWTs are used for stateless authentication. Use our free JWT Decoder to inspect token contents in your browser.
Introduction
A JWT (JSON Web Token) is a compact, URL-safe token format defined by RFC 7519 for securely transmitting information between parties as a JSON object. JWTs are widely used for authentication and authorization in web applications: after a user logs in, the server issues a JWT that the client includes in subsequent requests to prove identity. JWTs are stateless — the server does not need to look up the token in a database; the token itself contains the user's claims and a signature proving it was not tampered with.
Step by Step
-
Understand the three-part structure
A JWT has three parts: header (algorithm and type), payload (claims), and signature (proves integrity). Each part is Base64URL-encoded and separated by dots: eyJhbGciOi...J9.eyJzdWIi...J9.signature. The first two parts are readable by anyone with the token; only the signature requires the secret key.
-
Learn the standard claims
The payload contains claims — statements about the subject. Standard claims: 'sub' (subject/user ID), 'iat' (issued at timestamp), 'exp' (expiration), 'nbf' (not before), 'iss' (issuer), 'aud' (audience). Custom claims can include roles, permissions, or any other data.
-
Understand signing algorithms
JWTs use symmetric (HS256 — shared secret) or asymmetric (RS256, ES256 — public/private key pair) signing. The signature prevents tampering: changing any part of the token invalidates the signature. Only the holder of the secret/private key can create valid tokens.
-
Use JWTs for authentication
After login, the server creates a JWT and sends it to the client. The client includes the JWT in the Authorization header (Bearer token) for subsequent requests. The server verifies the signature and checks expiration — no database lookup needed.
Examples
JWT structure
Input: A typical JWT
Output: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyMSIsImV4cCI6MTY5MzYxMjgwMH0.signature
Decoded header
Input: First part decoded
Output: {"alg": "HS256", "typ": "JWT"}
Decoded payload
Input: Second part decoded
Output: {"sub": "user1", "name": "Alice", "iat": 1693526400, "exp": 1693612800}
Common Problems
- Decoding vs verifying —decoding a JWT (reading its contents) does NOT prove it is authentic. Always verify the signature server-side with the secret key before trusting claims.
- Storing JWTs in localStorage —this makes them accessible to JavaScript, vulnerable to XSS attacks. Store in httpOnly cookies for better security.
- Long-lived tokens —if a token is stolen, it remains valid until expiration. Use short-lived access tokens (15-60 min) with refresh tokens for long sessions.
- Sensitive data in payload —the payload is readable by anyone with the token (it is Base64, not encrypted). Never put passwords, credit cards, or secrets in the payload.
Tips
- Always verify the JWT signature server-side before trusting any claims —decoding alone is not authentication.
- Use short-lived access tokens (15-60 minutes) with refresh tokens for long sessions to minimize damage from token theft.
- Store JWTs in httpOnly, Secure, SameSite cookies rather than localStorage to prevent XSS attacks.
- Use our JWT Decoder to inspect token contents for debugging —your token never leaves your browser.