How JSON Web Tokens (JWT) Work: Structure, Claims & Decoding Explained

In modern web development, microservices, and single-page applications, JSON Web Tokens (JWT) (defined by RFC 7519) are the ubiquitous standard for stateless authentication and secure identity exchange.

Rather than maintaining heavy server-side session stores in memory or databases, a server issues a signed, tamper-evident cryptographic string that the client carries with every HTTP request in the Authorization: Bearer <token> header.

---

The Three-Part Structure of a JWT

A compact JWT is easily recognizable as three Base64Url-encoded strings concatenated by periods (.):

header.payload.signature

1. The Header (Red)

The header specifies the cryptographic metadata about how the token was signed:

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

• alg: The signing algorithm (e.g., HS256 for HMAC SHA-256, RS256 for RSA with public/private keys).
• typ: Token type (always "JWT").

2. The Payload (Claims) (Purple)

The payload contains the claims — statements about the authenticated entity (the user) and additional metadata:

{
  "sub": "user_12345",
  "name": "Jane Developer",
  "role": "admin",
  "iat": 1726982400,
  "exp": 1727068800
}

Standard Registered Claims:

• sub (Subject): The unique identifier of the user or principal.
• iss (Issuer): The identity provider that issued the token (e.g. https://auth.example.com).
• aud (Audience): The recipient or API service that this token is intended for.
• exp (Expiration Time): Unix epoch timestamp after which the token is invalid.
• nbf (Not Before): Timestamp before which the token must not be accepted.
• iat (Issued At): Timestamp when the token was created.

3. The Signature (Blue)

The signature ensures that the token has not been altered in transit:

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

If an attacker modifies the payload (for instance, changing "role": "user" to "role": "admin"), the resulting signature will not match, and the API server will reject the request.

---

Important Security Myth: JWTs Are NOT Encrypted by Default

A common misconception among beginner developers is that JWTs conceal sensitive data.

Base64Url encoding is NOT encryption! Anyone with access to the token can decode the header and payload in microseconds. Never store sensitive credentials (such as database passwords, plaintext secrets, or credit card numbers) in a standard JWS payload.

---

Inspect & Decode JWTs Safely

Debugging authentication headers or checking token expiration dates? Never paste sensitive production tokens into unknown third-party servers. Use our 100% client-side JWT Decoder — your tokens are parsed entirely in your browser's JavaScript engine with zero network transmission.