JWT Decoder Online: Inspect Token Headers, Payloads, and Claims Instantly

You've just received a 401 Unauthorized from an API you're integrating with. Is the token expired? Is the aud claim wrong? Did your auth server issue it with the wrong scope? The token itself — that long dot-separated string sitting in your Authorization header — contains all the answers. You just need to read it.

Toolzy's JWT Decoder lets you paste any JWT and immediately see its decoded header, payload, and a human-readable summary of key claims including the expiry time. No account, no server round-trip, instant results.

What Is a JWT?

A JSON Web Token (JWT, pronounced "jot") is a compact, self-contained way to represent information between two parties. It's the dominant format for authentication tokens in modern web applications: after you log in, the server issues you a JWT, and you send it with every subsequent request so the server knows who you are.

A JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
  .eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
  .SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

It has three parts separated by dots. Each part is Base64url-encoded. Decode them and you get structured data.

The Three Parts of a JWT

Part 1: The Header

The first segment encodes a JSON object that describes the token itself — specifically, the algorithm used to sign it:

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

The alg field tells you how the signature was created. Common values:

• HS256 — HMAC-SHA256, a symmetric signature using a shared secret
• RS256 — RSA-SHA256, an asymmetric signature using a private/public key pair
• ES256 — ECDSA with P-256 and SHA-256, compact asymmetric signatures
• none — no signature (dangerous; only acceptable in specific controlled scenarios)

The algorithm matters when you're debugging signature verification failures — if your server expects RS256 but the token was issued with HS256, verification will always fail regardless of key correctness.

Part 2: The Payload

The payload is the most useful part. It's a JSON object containing "claims" — assertions about the user or session:

{
  "sub": "user_abc123",
  "email": "user@example.com",
  "role": "admin",
  "iat": 1718780400,
  "exp": 1718784000,
  "aud": "https://api.example.com",
  "iss": "https://auth.example.com"
}

The JWT specification defines several "registered claims" with standard meanings:

| Claim | Meaning | |-------|---------| | sub | Subject — the user or entity the token represents | | iss | Issuer — the auth server that created the token | | aud | Audience — the service this token is intended for | | exp | Expiration time (Unix timestamp) | | iat | Issued at time (Unix timestamp) | | nbf | Not before — token isn't valid before this time | | jti | JWT ID — a unique identifier to prevent replay |

Beyond registered claims, any key-value pair can appear in the payload. Auth providers commonly include user roles, permissions, tenant IDs, email addresses, and custom application-specific data.

Part 3: The Signature

The third segment is a cryptographic signature over the first two parts. It lets a server verify that the token hasn't been tampered with since it was issued. The signature cannot be decoded into human-readable content — it's a raw cryptographic value.

A JWT decoder shows you the header and payload, which are just Base64url-encoded JSON. It does not and cannot verify the signature without the server's secret key. This is exactly what you want during debugging: you need to read the claims, not re-verify the token.

When Developers Reach for a JWT Decoder

Diagnosing 401 Unauthorized Errors

A 401 can mean any of several things: the token is expired, the aud doesn't match, the iss is wrong, the token was issued for a different environment (staging vs. production), or a required custom claim is missing. Decoding the token in seconds tells you which one.

Checking Token Expiry

The exp claim is a Unix timestamp. Without a decoder, you'd need to calculate Date(exp * 1000) mentally. A good JWT decoder converts it to a human-readable date and tells you whether the token is currently valid, already expired, or not yet valid.

Inspecting Token Contents During Development

When building a new feature that depends on a specific claim — a role, a tenant_id, a permissions array — you need to verify your auth server is actually including it. Copy the token from your browser's dev tools or network tab, paste it into the decoder, and confirm the claim is there with the right value.

Understanding Third-Party Auth Providers

Integrating with Auth0, Firebase Authentication, Cognito, Okta, or Supabase Auth? Each provider has its own payload structure and custom claims. Decoding a sample token from their documentation — or from a test account — shows you exactly what you'll receive and what keys to read.

API Development and Testing

If you're building an API that validates JWTs, you need to know what your test tokens actually contain. Decode them before writing your validation logic so you know the exact claim names and value formats to expect.

How to Use Toolzy's JWT Decoder

Go to toolzy.in/tools/jwt-decoder.

1. Paste your JWT into the input field. The token can be the raw string, or include the Bearer prefix — the tool strips it automatically.
2. See the decoded output instantly. The header and payload are displayed as formatted, syntax-highlighted JSON. Timestamps (exp, iat, nbf) are converted to human-readable dates alongside the raw Unix values.
3. Check the expiry status. A clear indicator shows whether the token is currently valid, expired, or not yet active — saving you the mental arithmetic on Unix timestamps.
4. Copy individual sections if you need to pass them to another tool or log them.

Everything runs in your browser. The token is never sent to any server.

Security: What You Should and Shouldn't Do with a JWT Decoder

Safe to do:

• Decode any JWT in a development, staging, or test environment
• Decode tokens from your own auth system to verify their contents
• Paste tokens from documentation or synthetic test accounts

Use caution with:

• Production tokens containing real user PII (email addresses, names, internal IDs). If you're debugging a production issue, consider whether you can reproduce it with a test token instead.

Never do:

• Paste tokens that contain sensitive secrets or credentials
• Assume that because a token is decodable it is valid — decoding is not verification
• Treat decoded claims as authoritative without server-side signature verification in your application code

A JWT decoder is a read-only tool for understanding token structure. Your application must always verify the signature server-side before trusting any claim.

JWT vs. Session Cookies: When Are JWTs Used?

JWTs are stateless — the server doesn't need to store anything to validate them. This makes them popular for:

• Microservices where multiple services need to trust the same identity without sharing a session store
• Mobile and SPA frontends that store the token locally and include it in API requests
• Cross-domain authentication where a cookie-based session won't travel between domains
• Short-lived API access tokens that expire quickly and don't need explicit revocation

Session cookies remain appropriate for traditional server-rendered applications where the server controls the session store.

Frequently Asked Questions

Can I verify the JWT signature with this tool? No. Signature verification requires the secret key or public key used to sign the token, which only your server holds. This tool decodes and displays the header and payload. Verification happens in your application code.

Is it safe to paste a JWT here? The tool runs entirely in your browser — nothing is transmitted to any server. That said, treat production tokens containing real user data with the same care as any sensitive credential. For debugging, prefer test tokens.

Why does the decoded payload contain timestamps instead of dates? JWT claims use Unix timestamps (seconds since January 1, 1970 UTC) because they're language-agnostic and compact. The decoder converts them to ISO 8601 dates for readability.

What does exp being in the past mean? An expired token (exp < current time) is rejected by most authorization servers. If your token is expired, you need to refresh it or re-authenticate.

Can a JWT be modified after it's issued? The payload is not encrypted — anyone can read it. But modifying the payload invalidates the signature, so a server performing proper signature verification will reject a tampered token.

---

Got a JWT you need to inspect? Paste it into the JWT Decoder and get a clear breakdown of every claim in seconds.