JWT Decoder: Understanding JSON Web Tokens
Learn how JSON Web Tokens (JWT) work, understand their three-part structure (header, payload, signature), and how to decode and debug JWTs for API authentication.
What Is a JWT?
A JSON Web Token (JWT, pronounced "jot") is an open standard (RFC 7519) for securely transmitting information between two parties as a JSON object. JWTs are widely used for authentication and authorization in modern web applications, APIs, and single sign-on (SSO) systems.
When a user logs in, the server generates a JWT and sends it to the client. The client stores this token (typically in localStorage or a cookie) and includes it in the Authorization header of subsequent requests. The server verifies the token's signature to confirm the user's identity without needing to look up session data in a database.
The key advantage of JWTs over traditional session tokens is that they are stateless — the server does not need to store session information. All the necessary data is embedded in the token itself.
The Three Parts of a JWT
A JWT consists of three Base64URL-encoded parts separated by dots:
- Header (purple) — The algorithm and token type
- Payload (orange) — The claims (data)
- Signature (green) — The verification signature
The Header
The header typically contains two fields:
alg— The signing algorithm (e.g., HS256, RS256, ES256)typ— The token type, usually "JWT"
Example decoded header:
The Payload (Claims)
The payload contains "claims" — statements about the entity (typically the user) and additional data. There are three types of claims:
| Claim | Type | Description |
|---|---|---|
| iss | Registered | Issuer of the token |
| sub | Registered | Subject (usually user ID) |
| exp | Registered | Expiration time (Unix timestamp) |
| iat | Registered | Issued at time |
| custom | Public/Private | Application-specific data |
The Signature
The signature is created by combining the encoded header and payload with a secret key using the algorithm specified in the header. For HS256 (HMAC-SHA256):
The signature ensures two things: (1) the token was issued by a trusted party who knows the secret, and (2) the header and payload have not been modified after signing. If even one character in the header or payload changes, the signature will not match.
Security Best Practices
- Never store sensitive data in the payload. JWTs are Base64URL-encoded, not encrypted. Anyone can read the payload.
- Keep tokens short-lived. Set
expto 15-60 minutes. Use refresh tokens for longer sessions. - Use strong algorithms. Prefer RS256 (RSA) or ES256 (ECDSA) over HS256 for production APIs.
- Validate all claims. Always check
exp,iss, andaudon the server side. - Store securely. Prefer httpOnly cookies over localStorage to prevent XSS attacks.
Try it now: Open the JWT Decoder Tool →
Paste any JWT and instantly decode its header, payload, and signature.
Frequently Asked Questions
What is a JWT?
A JWT (JSON Web Token) is a compact, URL-safe token format for securely transmitting information between parties. It consists of three Base64URL-encoded parts: a header, a payload, and a signature, separated by dots.
Is JWT encryption?
No. JWT is a signed token, not an encrypted one. The payload is Base64URL-encoded (not encrypted), meaning anyone can read it. The signature ensures the data has not been tampered with, but it does not hide the data.
How long should a JWT last?
Best practice is to keep JWT expiration short — typically 15 minutes to 1 hour for access tokens. Use refresh tokens to obtain new access tokens. Never create JWTs that never expire.