What is a JWT?

Welcome to this introduction on JSON Web Tokens (JWTs, pronounced “jot”)—a powerful way to transmit information between a client and server. Imagine you’re handing out party invitations. You need each invite to carry specific details (the guest’s name), but you don’t want to store a massive guest list on your end. What if you could issue each invite with a built-in guarantee that it hasn’t been forged or tampered with? That’s exactly how JWTs help you verify and trust specific pieces of data without server-side overhead.

Overview: Why JWTs?

A JSON Web Token is a token containing data (like a user’s info) in a format that can be verified but not necessarily hidden. JWTs let you:

• Identify or authorize a user without storing session data on the server.
• Verify that certain information has not been changed en route.
• Transparently send encoded payloads across systems, thanks to a standardized structure.

In practice, JWTs are often used for user authentication in modern web apps, single sign-on (SSO), or stateless session management.

Encoding, Encrypting, and Hashing

Before diving into JWT specifics, it’s crucial to understand the difference between these three concepts:

• Encoding: A reversible transformation of data into a different format. For instance, base64 encoding changes non-readable characters into readable ones. Anyone can decode it; no secret key needed.
• Encrypting: Hides data using a secret key so that only someone with the correct key can decrypt and read it. Encryption is reversible if you have the correct key.
• Hashing: Produces a “one-way” digest of the input. There’s no going back to the original data from the hash, but the same input will always yield the same hash. Hashing is typically used for password storage and for verifying data integrity.

JWTs use encoding for the visible parts of the token (header and payload) and hashing for the signature. They do not encrypt the payload by default.

Conceptual Overview: A Party Invite Example

Let’s picture JWTs through a party invite scenario:

• You’re hosting a party and want to give each guest a unique, tamper-proof invitation.
• You combine the guest’s email address and your secret password, run them through a hashing function, and send the guest an invite including:
  • Their email in plain text (for identification).
  • The hash (for verification).
• When the guest arrives, they show their invite. You take the email, re-hash it with your secret, and compare that output to the hash on the invite. If they match, you trust the invite. If not, it’s invalid.

This principle underpins JWTs: the token holds visible information, plus a signature that can be checked against a secret on the server.

Anatomy of a JWT

A JWT has three parts, each encoded in base64 and separated by periods (.):

header.payload.signature

The Header

The header typically contains two fields:

{
  "alg": "HS256",  // the hashing algorithm
  "typ": "JWT"     // the token type
}

In this case, the algorithm is HS256, which means a SHA-256 hashing algorithm with an HMAC secret.

The Payload

The payload is a JSON object with arbitrary data—often called “claims.” For example:

{
  "email": "johnny@gmail.com",
  "userId": 12345,
  "exp": 1691100000 // optional expiration timestamp
}

The payload is encoded, not encrypted, so anyone who intercepts the token can read these claims if they decode the base64 string. That’s why sensitive data like passwords or credit card numbers should never go here!

The Signature

The signature is where hashing comes in. It’s computed like:

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

The secret is kept on the server. This means if someone alters the header or payload, the signature check will fail on the server’s end.

Think of the payload as a “claim” and the signature as proof that the claim hasn’t been changed.

Putting It All Together

A JWT might look like this when combined:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9  // encoded header
.eyJlbWFpbCI6ImpvaG5ueUBnbWFpbC5jb20ifQ  // encoded payload
.SkuHIxgU1sDTrNKTTUIu9yDohUu8h0_4mbHiOMaUKwA  // signature

You can paste this JWT into the jwt.io sandbox to decode and examine the header and payload. If you provide the correct secret (like ILoveDogs in our earlier party example), the token will show as “signature verified.” Otherwise, it will appear invalid.

Common JWT Use Cases

Why use a JWT in your app? Common scenarios include:

• Stateless User Authentication: Store user ID and other info in the token, let the server verify the signature instead of tracking sessions.
• API Authorization: Microservices or third-party APIs can trust tokens without needing a central session store.
• Single Sign-On (SSO): Token-based auth across multiple domains or services.
• Information Exchange: Certain claims or data passed around reliably, knowing no one tampered with them.

What You Learned

In this reading, you’ve discovered:

• The difference between encoding, encrypting, and hashing: JWTs encode the header and payload, then hash them with a secret for the signature.
• How a JWT is structured: Header, payload, and signature—each with a specific role.
• Why the signature matters: It lets you verify that the token wasn’t tampered with.
• Core JWT use cases: Stateless auth, SSO, API security, and trusted data exchange.

JWTs are an elegant solution for many authentication and authorization challenges because they reduce or remove the need for server-side session storage. In the next steps, you’ll learn how to create (sign) and verify these tokens in practice, which is key to integrating JWT-based security into your applications.