Call
Security

JWT Explained: Header, Claims, Signatures, JWS vs JWE, and Common Misconceptions

A concise explanation of JWT structure and semantics covering headers, registered claims, signatures, JWS vs JWE, signing vs encryption, validation, and when opaque tokens may be simpler.

Published: December 2, 2025
Updated: September 10, 2026
2 min read
JWT Explained: Header, Claims, Signatures, JWS vs JWE, and Common Misconceptions

JWT Explained: Header, Claims, Signatures, JWS vs JWE, and Common Misconceptions

A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between parties. JWT is a token format—not automatically an authentication system, encryption format, or permission model.

What Is Inside a JWT?

A common signed JWT uses JWS compact serialization:

base64url(header).base64url(payload).signature

Header

Describes cryptographic metadata such as the signing algorithm and sometimes a key identifier.

Claims

The JSON payload can contain standard claims such as:

  • iss — issuer
  • sub — subject
  • aud — audience
  • exp — expiration
  • nbf — not before
  • iat — issued at
  • jti — token identifier

Applications decide which claims are required for their specific protocol/use case.

Signature

For a signed JWT, the signature/MAC protects integrity and authenticity according to the configured key and algorithm.

Rendering diagram…
Diagram generated from the article's Mermaid source.

JWT Is Not Automatically Encrypted

A normal JWS-signed JWT can usually be decoded by whoever holds it. The signature prevents undetected modification; it does not hide the claims.

If confidentiality is required, JOSE defines JWE for encryption. Often it is simpler to avoid placing sensitive information in the token at all.

JWS vs JWE

  • JWS — signed/MAC-protected data; common for access/identity tokens.
  • JWE — encrypted content.
  • A JWT can be represented using JWS or JWE according to RFC 7519.

The Token Must Still Be Validated

RFC 8725 requires callers to explicitly control accepted algorithms and validate claims such as issuer/audience according to the application's contract.

Simply decoding a JWT is not authentication. A token is trustworthy only after cryptographic and semantic verification succeeds.

JWT vs Opaque Token

JWTs are useful when a recipient benefits from locally verifiable claims. Opaque tokens can be simpler when the server needs centralized state, immediate revocation, or does not want claims exposed to clients.

Do not use JWTs merely because they are popular.

Final Takeaway

JWT is a compact claims format. Understand the distinction between JWT, JWS, and JWE; remember signed tokens are normally readable; and choose JWT only when self-contained verifiable claims actually improve your architecture.

References

Tags:JWTJWSJWEToken SecurityRFC 7519Authentication
AI & AGENT ENGINEERING

BUILDING AN AI PRODUCT?

Talk to Lofingo about custom autonomous AI agents, enterprise workflow automation, and scalable software systems.

EXPLORE AI SERVICES →