What is JWT? JSON Web Token Explained
A JSON Web Token (JWT) is a compact, URL-safe token format used to securely transmit information between parties as a JSON object. JWTs are the backbone of modern authentication systems — used in REST APIs, OAuth 2.0, OpenID Connect, and single sign-on (SSO) implementations worldwide.
The Three Parts of a JWT
A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature
Header
Specifies the token type (JWT) and the signing algorithm used, such as HS256 (HMAC-SHA256) or RS256 (RSA-SHA256).
{"alg": "HS256", "typ": "JWT"}
Payload
Contains the claims — statements about the user and additional metadata. Claims include standard fields like sub, exp, iat, and custom fields.
{"sub": "user123", "name": "Alice", "exp": 1700000000}
Signature
Created by signing the encoded header and payload with a secret key or private key. Used to verify the token hasn't been tampered with.
Full JWT Example
The three parts are Base64URL encoded and joined with dots to form the final token string that is sent in API requests.
How JWT Authentication Works
- User logs in — sends username and password to the authentication server
- Server verifies credentials — checks the database and validates the password
- Server issues JWT — creates a signed token containing the user's ID, roles, and expiry time
- Client stores JWT — typically in memory, localStorage, or an HttpOnly cookie
- Client sends JWT — includes the token in the
Authorization: Bearer <token>header on every API request - Server validates JWT — verifies the signature and checks expiry before processing the request
Standard JWT Claims
sub — Subject
The user or entity the token represents. Usually a user ID or account identifier.
exp — Expiration
Unix timestamp after which the token is no longer valid. Always set this to limit token lifetime.
iat — Issued At
Unix timestamp of when the token was created. Used to calculate token age.
iss — Issuer
Identifies who issued the token — typically your auth server URL or application name.
aud — Audience
Identifies the intended recipients of the token — your API or application identifier.
nbf — Not Before
Unix timestamp before which the token must not be accepted. Useful for delayed activation.
JWT vs Session Tokens
JWT (Stateless)
- No server-side storage needed
- Works across multiple servers (microservices)
- Self-contained — all info in the token
- Cannot be invalidated before expiry without a blocklist
Session Tokens (Stateful)
- Stored in server-side session store
- Can be invalidated instantly
- Requires sticky sessions or shared storage
- Better for applications requiring immediate logout
JWT Security Best Practices
- Always set an expiry — use short-lived access tokens (15 minutes to 1 hour)
- Use HTTPS — never transmit JWTs over unencrypted connections
- Store securely — prefer HttpOnly cookies over localStorage to prevent XSS attacks
- Validate the signature — always verify the token signature on the server before trusting claims
- Don't store sensitive data — JWT payloads are Base64 encoded, not encrypted — anyone can decode them
- Use refresh tokens — issue short-lived access tokens with longer-lived refresh tokens for better security
- Validate the algorithm — explicitly specify the expected algorithm to prevent algorithm confusion attacks
Common JWT Signing Algorithms
- HS256 — HMAC with SHA-256. Uses a shared secret. Simple but requires the same secret on all servers.
- RS256 — RSA with SHA-256. Uses a private/public key pair. The server signs with the private key; clients verify with the public key.
- ES256 — ECDSA with SHA-256. Smaller key sizes than RSA with equivalent security. Used in modern systems.
Paste any JWT to inspect its header, payload, claims, and expiry instantly.