developmentsecurityauthentication

JWT Tokens Explained: How to Decode and Read Them Without Code

JSON Web Tokens appear in every modern auth flow, but few developers know what's actually inside them. Learn how JWTs are structured, what each part means, and how to read them instantly in your browser.

·6 min read

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe string used to represent claims between two parties. You'll find them in Authorization headers, cookies, and query parameters across virtually every modern web application. They look like three Base64-encoded strings joined by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTcxNTAwMDAwMH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

That's it. Three parts, separated by dots.

The Three Parts

**Part 1 — Header** The first segment decodes to a JSON object that describes the token type and the signing algorithm:

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

Common algorithms: HS256 (HMAC-SHA256, symmetric key), RS256 (RSA, asymmetric), ES256 (ECDSA). The algorithm tells the verifying party how to check the signature.

**Part 2 — Payload** The payload is the most useful part. It contains "claims" — key-value pairs that assert something about the user or session:

{"sub": "user_123", "email": "user@example.com", "role": "admin", "iat": 1714000000, "exp": 1715000000}

  • sub — subject (usually a user ID)
  • iat — issued at (Unix timestamp)
  • exp — expiry (Unix timestamp) — the most important one to check
  • iss — issuer (which service issued this token)
  • aud — audience (which service should accept it)

**Part 3 — Signature** The signature is computed by the issuing server using a secret key or private key. Without the key, you cannot create a valid signature — but you can still read the header and payload without it.

Why You Can Read JWTs Without a Key

JWTs are Base64url-encoded, not encrypted. The header and payload are just encoded, not protected from reading. The signature only prevents *tampering* — it doesn't hide the contents. This is a common misconception: **never store sensitive data (passwords, payment info) in a JWT payload**. Anyone with the token string can decode and read it.

How to Decode a JWT in Seconds

Paste any JWT into NoxaKit's JWT Decoder. It splits the token into its three parts, decodes each segment, formats the JSON, and converts the iat/exp timestamps to readable dates — so you can instantly see when the token was issued and when it expires.

Useful for: debugging auth failures, checking which claims your backend is sending, verifying token expiry, and inspecting third-party tokens during integration.

Security Checklist When Working With JWTs

1. **Check exp first** — expired tokens should be rejected immediately 2. **Verify iss and aud** — a token from one service should not be accepted by another 3. **Never accept alg: none** — some libraries historically accepted unsigned tokens 4. **Use short expiry times** — 15-60 minutes for access tokens; use refresh tokens for longer sessions 5. **Store tokens correctly** — httpOnly cookies are safer than localStorage against XSS

Building JWTs for Testing

NoxaKit's JWT Builder lets you construct tokens with any payload and sign them with an HMAC-SHA256 secret — useful for writing integration test fixtures or debugging JWT verification logic without setting up a full auth server.

Try These Free Tools

More Articles