Decoding a JWT token, step by step.

The anatomy of a JWT

A JSON Web Token has three Base64-encoded parts, separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhbGljZSIsImlhdCI6MTcxNTAwMDAwMH0.A8aB...

• Header. Algorithm and token type, e.g., {"alg":"HS256","typ":"JWT"}.
• Payload. The claims — who the token is about, when it expires, what it grants.
• Signature. Proves the header and payload haven't been altered since the issuer signed them.

Each part is URL-safe Base64 (the variant with - and _ instead of + and /, and no padding). The header and payload are JSON. The signature is binary.

Decoding a JWT step by step

1. Split the token on dots.
2. Take the first part (header) and Base64-decode it. You'll get JSON like {"alg":"HS256","typ":"JWT"}.
3. Take the second part (payload) and Base64-decode it. You'll get the claims as JSON.
4. Leave the third part alone for now — it only matters during verification.

Paste either segment into the decoder and you'll see the JSON. The decoder handles the URL-safe alphabet and missing padding automatically.

Common claims you'll see

Claim	Meaning
iss	Issuer — who created the token
sub	Subject — who the token is about (user ID)
aud	Audience — who the token is intended for
exp	Expiration time (Unix timestamp)
nbf	Not-before time
iat	Issued-at time
jti	JWT ID — unique identifier for the token

What decoding does NOT do

This is the most important part of the article. Decoding a JWT only reveals what's inside it. It does not:

• Verify the signature. Anyone can forge a JWT with arbitrary claims if you don't check the signature.
• Check expiration. The exp claim is just a number until something compares it to "now."
• Confirm the issuer. The iss claim is whatever the token says.

If you're treating JWTs as authentication, you must verify the signature server-side with the issuer's key, and you must check exp and aud. Use a library — never roll your own.

Why JWTs use URL-safe Base64

JWTs travel in URLs (OAuth redirects), HTTP headers (Authorization: Bearer ...), and cookies. Each of these contexts dislikes +, /, and =. URL-safe Base64 lets a JWT be passed anywhere without escaping. (Full URL-safe explainer here.)

The "none" algorithm trap

A historic JWT vulnerability: tokens with {"alg":"none"} in the header are unsigned. A naive verifier that respects the alg field will accept any payload as valid. Always reject alg: none unless you have a specific, deliberate reason to allow it.

When to skip the library and use this tool

For inspecting tokens during debugging — what claims is this token carrying? what's the expiration? — paste it into the decoder. It's faster than writing code. For production verification, use a vetted JWT library in your language.

---

Published May 2026 · Last reviewed May 2026. Spot an error? Email contactus@base64decode.tools.