JWT structure explained: header, payload, and security

What is a JWT: Compact, Stateless Claims

JSON Web Token (JWT) is an open industry standard (RFC 7519) designed for securely transmitting assertions between parties as a compact JSON object. JWTs are overwhelmingly employed in modern cloud architectures, single-page applications, and microservices for stateless user authentication and fine-grained authorization.

The standout advantage of standard JWT architecture is that it is stateless. An API gateway or downstream microservice does not need to query a central session store (like Redis or PostgreSQL) on every inbound HTTP request. All pertinent contextual assertions (user ID, tenant, role permissions, expiration time) are contained within the token, and mathematical signatures guarantee integrity.

Anatomy of a JWT: Three Dot-Separated Segments

A valid JSON Web Token consists of three distinct components separated by periods: header.payload.signature

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

{
  "sub": "user_98412",
  "name": "Alex Miller",
  "role": "editor",
  "iat": 1792929600,
  "exp": 1792933200
}

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

Standard Registered Claims (RFC 7519)

To ensure cross-language interoperability between authentication providers and consumers, the specification reserves seven standard claims:

5 Critical JWT Security Vulnerabilities

1. Blindly Trusting the "alg: none" Header

An infamous historical design flaw. When an authentication backend dynamically trusts the algorithm header supplied by the client, an attacker can submit a modified payload with {"alg": "none"} and an empty signature. Backend verifiers must strictly enforce expected signing algorithms in code: jwt.verify(token, secret, { algorithms: ['HS256'] }).

2. Algorithm Confusion Attacks (RS256 to HS256)

In systems utilizing asymmetric RS256, the server's public key is publicly accessible. Attackers change the token header algorithm to symmetric HS256 and sign the token using the server's public RSA key. If the backend fails to verify the expected algorithm type, it verifies the HMAC signature using the public key string, granting full unauthorized access.

3. Missing or Unvalidated Expiration (exp)

A token without an exp claim never expires. If an access token leaks through reverse proxy logs or compromised browser storage, attackers retain permanent persistence. Access tokens should have an active window of 5 to 15 minutes, coupled with secure refresh token rotation.

4. Leaking Production Tokens to Third-Party Online Decoders

Engineers frequently paste live production bearer tokens into random web-based decoders during debugging sessions. If that service logs payload contents or transmits tokens to third-party tracking scripts, credentials with administrative scope become compromised.

Always inspect tokens with zero-network, client-side tools. Our JWT Decoder executes entirely within your local browser sandbox via the native Web Crypto API: no tokens or secrets ever leave your machine.

5. Storing Sensitive Tokens in localStorage (XSS Exposure)

Any JavaScript executing on the page has full read access to window.localStorage. A single compromised supply-chain dependency or script injection vulnerability allows silent extraction of your bearer tokens. For browser applications, store session refresh credentials in HttpOnly, Secure cookies.

How to Decode JWT Payloads in Lightweight JavaScript

Because the header and payload are standard Base64Url strings, you can parse token claims in vanilla JavaScript without heavy dependencies:

function parseJwtPayload(token) {
  const base64Url = token.split('.')[1];
  if (!base64Url) throw new Error('Invalid JWT format');
  
  const base64 = base64Url.replace(/-/g, '+').replace(/_/g, '/');
  const jsonPayload = decodeURIComponent(
    atob(base64)
      .split('')
      .map(c => '%' + ('00' + c.charCodeAt(0).toString(16)).slice(-2))
      .join('')
  );

  return JSON.parse(jsonPayload);
}