How to jwt works

Content on WhatAnswers is provided "as is" for informational purposes. While we strive for accuracy, we make no guarantees. Content is AI-assisted and should not be used as professional advice.

Last updated: April 4, 2026

Quick Answer: JSON Web Tokens (JWTs) are a compact, URL-safe means of representing claims to be transferred between two parties. They consist of three parts: a header, a payload, and a signature, separated by dots. The header and payload are base64-encoded JSON objects, while the signature verifies the token's integrity and authenticity.

Key Facts

JWTs are stateless, meaning the server doesn't need to store session information.
A standard JWT is composed of 3 parts: Header, Payload, and Signature.
The header typically contains the type of token (JWT) and the hashing algorithm used (e.g., HMAC SHA256 or RSA).
The payload contains the claims, which are statements about an entity (typically, the user) and additional data.
The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message was not changed along the way.

What is a JSON Web Token (JWT)?

A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs are commonly used for authentication and information exchange in web applications and APIs.

How Does a JWT Work?

A JWT is structured into three parts, separated by dots ('.'). These parts are:

Header: This section is a JSON object that describes the token's metadata. It typically contains two key-value pairs: the type of the token ('typ', which is 'JWT') and the signing algorithm ('alg') being used (e.g., 'HS256' for HMAC SHA256, 'RS256' for RSA SHA256). This header is then Base64Url encoded.
```
{"alg": "HS256","typ": "JWT"}
```
Payload: This section contains the actual claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims:
- Registered Claims: These are a set of predefined claims that are not mandatory but recommended to provide helpful sets of useful, interoperable claims. Examples include 'iss' (issuer), 'exp' (expiration time), 'sub' (subject), 'aud' (audience), 'iat' (issued at time), 'nbf' (not before time), and 'jti' (JWT ID).
- Public Claims: These are claims that can be defined by those using JWTs but should be defined to avoid collisions. They are typically defined by the URI identifier.
- Private Claims: These are custom claims created to share information between parties that have no claims in common.
The payload is also Base64Url encoded.
```
{"sub": "1234567890","name": "John Doe","iat": 1516239022}
```
Signature: To create a signature, a sequence of two encoded strings (header and payload) is taken, a secret (using the algorithm specified in the header) is applied, and the result is the signature. The signature is used to verify that the sender of the JWT is who it says it is and to ensure that the message was not changed along the way. The signature is also Base64Url encoded.
```
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
```

How JWTs are Used (e.g., Authentication)

JWTs are particularly useful for securely transmitting information between parties. A common use case is authentication. Here's a typical flow:

User Login: A user logs in with their credentials (e.g., username and password).
Server Verification: The server verifies these credentials.
Token Generation: Upon successful verification, the server generates a JWT containing the user's identity (e.g., user ID, roles) and an expiration time. This token is signed by the server using a secret key.
Token Issuance: The server sends the JWT back to the client (e.g., web browser).
Subsequent Requests: For subsequent requests to protected resources, the client includes the JWT in the 'Authorization' header, typically with the scheme 'Bearer'. For example: Authorization: Bearer <token>.
Token Verification: When the server receives a request with a JWT, it verifies the token's signature using its secret key. If the signature is valid and the token has not expired, the server trusts the claims within the token and allows access to the protected resource. If the token is invalid or expired, the server rejects the request.

This stateless nature of JWTs means the server doesn't need to maintain session state for each user, as all the necessary information is contained within the token itself. This can improve scalability and performance.

Advantages of JWTs

Compact: JWTs are small, making them easy to transmit in URL, parameter, or header.
Self-contained: The payload contains all the necessary information, reducing the need for database lookups for user data during request processing.
Stateless: Servers don't need to store session state, which simplifies architecture and improves scalability.
Decoupled: JWTs allow for decoupled architectures, where authentication services can be separate from resource servers.

Disadvantages and Security Considerations

Payload is not encrypted: The payload is only Base64Url encoded, meaning it can be easily decoded and read by anyone. Sensitive information should never be placed in the payload unless the JWT is encrypted (JWE - JSON Web Encryption).
Token size: If the payload contains too much data, the JWT can become large, impacting performance.
Security of the secret key: If the secret key used for signing is compromised, attackers can forge JWTs.
Expiration: Tokens should always have an expiration time to limit the window of opportunity for attackers if a token is stolen.
Revocation: Revoking JWTs before they expire can be challenging due to their stateless nature. Solutions often involve maintaining a blacklist of revoked tokens on the server, which can add some statefulness back into the system.

In summary, JWTs are a powerful tool for secure information exchange and authentication, but they must be implemented carefully, paying close attention to security best practices.