What is a JWT Token? A Complete Beginner's Guide

Introduction

If you have worked with modern web applications or APIs, you have probably wondered what is a JWT token and why it is so widely used. JWT stands for JSON Web Token, a compact and URL-safe token format for securely transmitting information between parties as a JSON object. JWTs are the backbone of authentication in countless web applications, mobile apps, and APIs.

A JWT token is not just a random string—it is a structured token containing verifiable information about a user or client. Unlike traditional session-based authentication where servers store session data, a JWT is self-contained. The token carries all the information needed to verify a user’s identity, making it ideal for distributed systems and microservices.

In this guide, you will learn what a JWT token is, how its three parts work together, the authentication flow, JWT vs session tokens, common use cases, and important security best practices.

What is a JWT Token?

A JWT (JSON Web Token) is an encoded string consisting of three Base64-encoded parts separated by dots: the header, the payload, and the signature. Unlike opaque session IDs that require server-side lookups, a JWT is self-contained—it carries all the user information needed for authentication within the token itself. This stateless property makes JWTs highly scalable and perfect for distributed systems.

Think of a JWT as a digital passport. When a user logs in, the server issues a JWT that contains the user’s identity and permissions. The client presents this token with each request, and the server can verify it without consulting a database. This eliminates the need for server-side session storage and enables horizontal scaling across multiple servers.

JWT Structure: Header, Payload, and Signature

Every JWT consists of three parts separated by dots. Understanding the JWT structure is essential for working with tokens effectively. Here is an example JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The Header

The header is the first part of a JWT. It contains metadata about the token including the type (typ) which is always JWT, and the signing algorithm (alg) such as HS256 or RS256.

{
  "alg": "HS256",
  "typ": "JWT"
}

The header tells the server how the token was signed. The algorithm field is critical—if an attacker changes it, signature verification detects the tampering.

The Payload

The payload is the second part and contains the claims, which are statements about the user and metadata. There are three claim types: registered claims (predefined like iss, exp, sub, iat), public claims (custom), and private claims (agreed between parties).

{
  "sub": "1234567890",
  "name": "Alice",
  "email": "alice@example.com",
  "iat": 1719619200,
  "exp": 1719705600
}

Common registered claims include sub (user ID), iat (issued at), exp (expiration), iss (issuer), and aud (audience). The payload is Base64-encoded, not encrypted—anyone with the token can read it. Never put sensitive data like passwords in the payload.

The Signature

The signature is the third and most important part. It cryptographically ensures the token has not been tampered with. It is created by taking the encoded header and payload, concatenating them with a dot, and signing with a secret key using the algorithm in the header.

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

When a server receives a JWT, it recalculates the signature. If it matches, the token is authentic. If someone modified the payload or header, the signature verification fails and the token is rejected.

JWT vs Session Tokens

Traditional session-based authentication stores session data on the server. When a user logs in, the server creates a session record, sends a session ID cookie to the client, and looks up the session on every request. This approach works but has scalability limitations.

Storage: Sessions require server-side storage (memory or database). JWTs store everything in the token itself—no server-side storage needed.

Scalability: Sessions need a shared store (like Redis) across multiple servers. JWTs are stateless—any server can verify them independently.

Performance: Sessions require a database lookup on every request. JWTs can be verified locally with just a signature check, making them faster.

Revocation: Sessions can be revoked instantly by deleting the session record. JWTs remain valid until they expire, unless you implement a token blacklist which adds complexity.

Cross-domain: Sessions are tied to a single domain via cookies. JWTs work across different domains and services, making them ideal for SSO and microservices.

How JWT Works Step by Step

The JWT authentication flow follows these steps:

Step 1: User Logs In — The user submits credentials (username and password) to the server’s login endpoint via HTTPS.

Step 2: Server Verifies Credentials — The server checks the password against the stored hash. If valid, the server creates a JWT.

Step 3: Server Creates the JWT — The server constructs a JWT with the user’s ID, issued-at time, expiration, and other claims, signs it, and sends it back.

Step 4: Client Stores the Token — The client stores the JWT (localStorage, sessionStorage, or HTTP-only cookie).

Step 5: Client Sends the Token — For each request, the client includes the JWT in the Authorization header: Authorization: Bearer [token].

Step 6: Server Verifies — The server extracts the JWT, verifies the signature, checks expiration, and processes the request. No database lookup needed.

Common Use Cases for JWT

Single Sign-On (SSO): A single JWT works across multiple applications and domains. The user logs in once and accesses all participating services. This is why enterprise systems and large platforms rely on JWT for SSO.

Mobile App Authentication: Mobile apps do not use cookies natively. JWTs are perfect because the app stores the token locally and sends it in headers. This works consistently across iOS and Android.

API Authentication: RESTful APIs use JWTs to authenticate requests. The API gateway validates the JWT before forwarding requests to microservices, eliminating the need for each service to implement authentication.

OAuth2 and OpenID Connect: JWTs are the standard token format in OAuth2 and OpenID Connect protocols. When you log in with Google or GitHub, the identity tokens returned are JWTs.

Security Tips for JWT Tokens

1. Always Use HTTPS: Transmit JWTs exclusively over HTTPS. If intercepted over HTTP, an attacker can steal the token and impersonate the user.

2. Set Short Expiration: Access tokens should expire in 15-60 minutes. Use refresh tokens for longer sessions. Short-lived tokens limit damage if stolen.

3. Keep Secret Keys Secure: Store signing keys in environment variables or secrets managers. Never commit them to version control. A compromised key lets attackers forge tokens.

4. Validate All Claims: Check the signature, expiration, issuer, and audience. Use reputable JWT libraries that handle validations automatically.

5. Use RS256 in Production: Asymmetric signing (RS256) uses a private key to sign and a public key to verify. Multiple services can verify tokens without sharing the secret key, reducing the attack surface.

Frequently Asked Questions

What is a JWT token used for?

A JWT token is primarily used for authentication and authorization in web applications, APIs, and mobile apps. It securely transmits user identity and permissions between the client and server without requiring server-side session storage.

Is JWT encryption or encoding?

JWT uses Base64 encoding for the header and payload, not encryption. The content is readable by anyone who has the token. The signature verifies integrity but does not hide the data. For sensitive data, use JWE (JWT Encryption).

How long does a JWT token last?

JWT expiration is set by the exp claim. Access tokens typically last 15 minutes to 1 hour. Refresh tokens can last days or weeks. Short expiration limits damage if a token is compromised.

Can a JWT be revoked?

JWTs cannot be revoked before expiration unless you maintain a token blacklist, which adds server-side state and defeats the stateless advantage. This is why short expiration times are recommended.

What happens if a JWT signature is invalid?

If the signature does not match, the token has been tampered with. The server rejects it with a 401 Unauthorized error. Never trust a JWT with an invalid signature—it may be a forged token from an attacker.

Start Using JWT Tokens Today

Understanding what a JWT token is and how it works is essential for modern web development. JWTs provide stateless, scalable authentication that works across distributed systems, mobile apps, and SSO environments. The three-part structure (header, payload, signature) enables secure, self-contained authentication without server-side session storage.

Use our free JWT Decoder online to instantly inspect and decode any JWT token. See the header, payload, and signature in clear JSON format—no signup required.

---