Understanding JWT: How It Works, Use Cases, and Best Practices

As a web app developer, you may be familiar with how JWTs work, or perhaps you’ve used them without fully grasping the architecture. A JWT, or JSON Web Token, is widely popular today—especially for managing user identity, authorization, and secure data exchange.

But what exactly is a JWT (JSON Web Token)? How does it function, and why have most developers shifted from session-based authentication to JWTs?

Don’t worry if it seems complex—we’ll break it all down. You’ll learn what a JWT is, how it works, real-world use cases, and best practices to apply. Whether you're a beginner or looking to deepen your understanding, this blog is for you.

🛡️ What is JWT?

JWT stands for JSON Web Token. It’s an open standard (RFC 7519) used to securely transmit information between two parties—typically a server and a client—as a JSON object.

At its core, a JWT is just a string that contains some data (called claims) that can be verified and trusted because it’s digitally signed. This signature ensures the data hasn’t been tampered with.

JWTs are most commonly used for authentication. Once a user logs in, the server generates a token and sends it back to the client. The client includes this token in the headers of future requests, allowing the server to verify the user without checking a session or database each time.

📦 JWT Structure

A JWT has three parts, separated by dots (.):

xxxxx.yyyyy.zzzzz

These parts are:

1. Header – Contains the type of token (JWT) and the signing algorithm used (e.g., HS256).
2. Payload – Contains the claims or actual data you want to send (like user ID, email, role, etc.).
3. Signature – A hash created using the header, payload, and a secret key. This is what makes the token secure and verifiable.

Here’s a decoded example:

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

Payload:
{
  "userId": "12345",
  "email": "user@example.com",
  "role": "admin"
}

🧠 Key Thing to Remember

A JWT doesn’t hide the data—it just ensures it hasn’t been changed. The payload is Base64 encoded, not encrypted. So anyone with the token can decode and read the contents.

Never store sensitive information (like passwords) in a JWT.

🔐 How JWT Signing Works (Not Encryption)

When a server generates a JWT, it signs the token using:

• A secret key using HMAC (e.g., HS256)
• Or a private key using RSA/ECDSA (e.g., RS256)

The signature acts like a seal of trust. When the client sends the token back, the server recalculates the signature and compares it to ensure nothing has changed.

🕵️‍♂️ So... Can Anyone Read the Payload?

Yes—unless you encrypt the JWT using a separate standard like JWE (JSON Web Encryption). But most JWT implementations are signed, not encrypted.

That’s why you should only store non-sensitive information like user ID, role, or email.

🛡️ Summary

• Signing ≠ Encryption: Signing ensures the token wasn’t changed. Encryption hides the data.
• JWTs are typically signed using a secret or private/public key pair.
• The server uses the signature to verify the token’s integrity.
• If you need to hide the payload data, use JWT encryption with JWE.