Wat Is een JWT? Een Volledige Uitleg van JSON Web Tokens
Quick Answer
Een JWT is een tekenreeks met drie Base64URL-gecodeerde delen gescheiden door punten: header.payload.signature. De header specificeert het algoritme, de payload bevat claims (user ID, roles, expiration) en de signature bewijst authenticiteit. Gebruik onze gratis JWT Decoder om token-inhoud in je browser te inspecteren.
Introduction
Een JWT (JSON Web Token) is een compact, URL-safe token-formaat gedefinieerd door RFC 7519 voor het veilig verzenden van informatie tussen partijen als een JSON-object. JWT's worden veel gebruikt voor authenticatie in webapplicaties: na login geeft de server een JWT die de client in volgende requests meestuurt. JWT's zijn stateless —de server hoeft het token niet in een database op te zoeken; het token zelf bevat de claims en een signature.
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.