What is a JWT?
A JWT (JSON Web Token) is an open standard (RFC 7519) that defines a compact, self-contained way to securely transmit information between two parties as a JSON object. The information is digitally signed, which means it can be verified and trusted.
JWTs are most commonly used for authentication: once a user logs in, the server issues a JWT. The client includes that token in subsequent requests, and the server validates it without needing to query a database on every call.
The three parts of a JWT
A JWT is a string of three base64url-encoded parts separated by dots:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyLCJleHAiOjE3MTYyNDI2MjJ9.r8d5mFpCpFTKJzn0xqQ4p9klO8KxD2yKpBiAqJf1234Header
The header declares the token type (JWT) and the signing algorithm (alg). After base64url decoding:
{"alg": "HS256", "typ": "JWT"}Payload
The payload contains claims — statements about the user or additional data. Standard claims include:
sub— subject (usually the user ID)iat— issued at (Unix timestamp)exp— expiration time (Unix timestamp)iss— issuer (who created the token)aud— audience (who the token is intended for)
{"sub": "1234567890", "name": "Jane Doe", "iat": 1716239022, "exp": 1716242622}Signature
The signature is computed by taking the encoded header and payload, joining them with a dot, and signing with the algorithm and a secret key:
HMACSHA256(base64url(header) + "." + base64url(payload), secretKey)The signature guarantees that the token hasn't been tampered with. If anyone modifies the payload, the signature no longer matches and the server rejects the token.
This site's JWT Decoder splits a token like this one into its three parts and shows the decoded header and payload.
How JWT authentication works
- Login — the user submits credentials. The server verifies them and creates a signed JWT.
- Storage — the client receives the token and stores it (cookie or memory).
- Request — on each API call, the client sends the token in the
Authorizationheader:Authorization: Bearer <token> - Verification — the server validates the signature and checks
exp. If valid, the request is authorized. No database lookup needed.
Signing algorithms
HS256 / HS384 / HS512Symmetric (HMAC)Single service — one shared secret for both signing and verificationRS256 / RS384 / RS512Asymmetric (RSA)Distributed systems — private key signs, public key verifies (services don't need the secret)ES256 / ES384 / ES512Asymmetric (ECDSA)Same as RSA but smaller tokens and faster operationsWhen in doubt, use HS256 for simple internal services and RS256 when multiple services need to verify tokens without sharing a secret.
Security best practices
- Always verify the signature — never decode a JWT and trust the payload without checking the signature first.
- Check the
expclaim — reject expired tokens even if the signature is valid. - Use short expiration times — 15–60 minutes for access tokens, longer for refresh tokens.
- Store in HttpOnly cookies — immune to XSS attacks, unlike localStorage.
- Use HTTPS — tokens in transit must be encrypted.
- Validate the
algheader — some libraries historically accepted"alg": "none", bypassing signature verification entirely. Always enforce the expected algorithm server-side.