JWT Token Example: Anatomy of a Real Token, Explained

JWT Token Example: Anatomy of a Real Token, Explained

A JWT token example is the quickest way to understand how JSON Web Tokens work, because a JWT is just three Base64URL-encoded strings joined by dots: header.payload.signature. The header says how the token is signed, the payload carries the claims (who the user is and what they can do), and the signature proves the token has not been tampered with. This post breaks down a real JWT token example piece by piece, shows you the decoded contents, and explains how verification actually works.

Here is the direct answer if you are in a hurry. A JWT looks like eyJhbGciOi... split into three sections by periods. Split on the dots, Base64URL-decode the first two parts to read plain JSON, and the third part is a cryptographic signature that only the server can recompute. To see this instantly with your own token, paste it into the free JWT Decoder and read the header and payload in human-friendly JSON.

The Three Parts of a JWT

Every JSON Web Token has exactly three segments. Understanding what each does removes nearly all the mystery around tokens.

• Header — metadata about the token, primarily the signing algorithm (alg) and the token type (typ).
• Payload — the claims: statements about the user and the token itself, such as subject, expiry, and roles.
• Signature — a hash of the header and payload signed with a secret or private key, used to verify integrity and authenticity.

Critically, the header and payload are only encoded, not encrypted. Anyone holding the token can read them. The signature is what makes a JWT trustworthy: change a single character in the payload and the signature no longer matches, so the server rejects it.

A Complete JWT Token Example, Decoded

Below is a compact, realistic token. It is wrapped here for readability, but in transit it is one continuous string with no spaces.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxODIzMDQwMCwiZXhwIjoxNzE4MjM0MDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

When you split on the dots and decode the first two segments, you get clean JSON. The header decodes to this.

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

And the payload decodes to this set of claims.

{ "sub": "1234567890", "name": "Ada Lovelace", "role": "admin", "iat": 1718230400, "exp": 1718234000 }

The third segment, SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c, is the signature. It is not human-readable JSON; it is the HMAC-SHA256 of the encoded header and payload using a server-side secret. You verify it by recomputing the same hash and comparing.

What the standard claims mean

Claims like role and name above are custom (private) claims you add for your own application. Keep them minimal: every claim adds bytes to a token that travels on every request. To inspect any of these fields in a real token of yours, drop it into the JWT Decoder and the claims appear formatted automatically.

How the Signature Is Built and Verified

The signature ties the three parts together. For the HS256 algorithm in our example, the formula is straightforward HMAC.

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

When a request arrives, the server takes the header and payload exactly as received, recomputes the HMAC with its own secret, and compares the result to the signature in the token. If they match, the token is authentic and untampered. If even one byte of the payload changed, the recomputed hash differs and verification fails. This is why you must never trust a JWT's claims without verifying the signature first.

Symmetric vs. asymmetric signing

HS256 is symmetric: the same secret signs and verifies, so every verifier must hold the secret. RS256 is asymmetric: a private key signs and a public key verifies, which is safer when many independent services need to verify but only one should be able to issue. Choose RS256 when third parties verify your tokens, and HS256 only when issuer and verifier are the same trusted service.

Decoding a JWT in Code

In production you should always verify, not just decode. Here is a Python example using the popular PyJWT library that both checks the signature and reads the claims.

import jwt token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." secret = "your-256-bit-secret" try: claims = jwt.decode(token, secret, algorithms=["HS256"]) print("Verified. User:", claims["sub"], "Role:", claims["role"]) except jwt.ExpiredSignatureError: print("Token expired") except jwt.InvalidTokenError: print("Invalid signature or malformed token")

The equivalent in Node.js with jsonwebtoken follows the same pattern: verify with the secret and the allowed algorithm, then use the returned claims.

import jwt from "jsonwebtoken"; try { const claims = jwt.verify(token, secret, { algorithms: ["HS256"] }); console.log("Verified user", claims.sub); } catch (err) { console.log("Rejected:", err.message); }

Security Mistakes to Avoid

1. Putting secrets in the payload. The payload is readable by anyone. Never store passwords, API keys, or sensitive personal data in it.
2. Skipping signature verification. Decoding is not validation. Always verify the signature before trusting any claim.
3. Accepting alg: none. A classic attack sets the algorithm to none to bypass signing. Always pass an explicit allow-list of algorithms.
4. Ignoring exp. Long-lived tokens are dangerous if stolen. Keep access tokens short and refresh them.
5. Storing tokens insecurely. Keep them out of URLs and consider HttpOnly cookies to reduce exposure to cross-site scripting.

Treat a JWT's payload like a postcard: anyone along the way can read it. The signature is the wax seal that proves it was not altered, not a lock that hides the contents.

For more developer utilities in the same family, the development tools hub collects formatters, validators, and decoders that pair well with day-to-day token work.

Where JWTs Fit With Other Tasks

Tokens rarely live in isolation. The sub claim above is often a stable identifier you generate elsewhere; our guide to generating UUIDs in Python is handy when you need unique subject IDs. Because the decoded payload is plain JSON, you can lint and structurally diff two tokens' claims with a JSON compare to spot which permissions changed between sessions. And if you parse tokens out of headers or logs with text rules, the regex cheat sheet helps you match the three-dot structure reliably.

Frequently Asked Questions

What does a JWT token look like?

It is a single string made of three Base64URL-encoded parts separated by dots, in the form header.payload.signature. It usually begins with eyJ because that is the encoded start of a JSON object.

Is a JWT encrypted?

No. A standard signed JWT is encoded, not encrypted. The header and payload can be decoded and read by anyone who has the token. Only the signature is cryptographic, and it proves integrity rather than hiding the contents.

Can I read a JWT without the secret?

Yes, you can decode and read the header and payload without any secret, because they are just Base64URL-encoded JSON. You cannot verify the signature or trust the token without the secret or public key. The JWT Decoder reads the claims instantly in your browser.

What is the difference between HS256 and RS256?

HS256 uses one shared secret for both signing and verifying. RS256 uses a private key to sign and a public key to verify, which is better when multiple parties must verify tokens but only one should issue them.

Why is my JWT being rejected?

The most common reasons are an expired exp claim, a signature mismatch from the wrong secret or key, a tampered payload, or an algorithm that does not match what the server expects. Decode the token first to inspect exp and alg before debugging further.

Should I store sensitive data in a JWT?

No. Because the payload is readable, never include passwords, secrets, or sensitive personal data. Store only identifiers and non-sensitive claims, and keep the payload small since it travels on every request.

How do I decode a JWT online safely?

Use a client-side decoder that runs entirely in your browser so the token never leaves your machine. Paste it into the JWT Decoder to read the header and payload as formatted JSON with no signup required.