Developer Tools
Verified Tool

JWT Decoder

Decode and inspect JSON Web Tokens

Start Using JWT Decoder Now
Free Forever No Signup
Last Updated: March 2, 2026
avatarBy Viblaa Team

Header/payload display

Expiration checking

Timestamp formatting

Copy sections

The API returns 401 Unauthorized. Your auth code looks right. You're passing the token. But something's wrong, and the error message is useless.

You copy the JWT from your request headers. It's a wall of base64 gibberish separated by dots. What's in there? Is the token expired? Is the audience wrong? Is the user ID what you expect?

This decoder unpacks JWTs instantly—showing headers, claims, and timestamps in human-readable format. Debug authentication in seconds instead of hours.

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe token format used for authentication and information exchange. It consists of three base64-encoded parts separated by dots: Header, Payload, and Signature.

Structure:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4ifQ.signature

[Header].[Payload].[Signature]
JWTs Are Not Encrypted

JWTs are encoded, not encrypted. Anyone can decode the header and payload—the signature only proves they weren't tampered with. Never put sensitive data in a JWT.

Why People Actually Need This Tool

JWTs Power Modern Authentication

OAuth, OpenID Connect, API authentication—JWTs are the standard token format. Understanding what's inside them is essential for debugging auth issues.

  1. Debugging 401 errors — Check if tokens are expired, have wrong claims, or are malformed.

  2. Verifying user context — Confirm the token contains expected user ID, roles, and permissions.

  3. API development — Inspect tokens during authentication flow development.

  4. Security auditing — Review what data your application exposes in tokens.

  5. Learning OAuth/OIDC — Understand token structure by examining real examples.

  6. Troubleshooting SSO — Debug single sign-on issues across systems.

  7. Token lifecycle management — Check expiration and issued-at times.

How to Use the JWT Decoder

  1. Paste your JWT — The complete token string with all three parts.

  2. View decoded header — See algorithm, type, and key identifier.

  3. Inspect payload — Read all claims including subject, expiration, and custom data.

  4. Check timestamps — Instantly see when the token was issued and when it expires.

ClaimFull NamePurpose
issIssuerWho created the token
subSubjectWho the token represents (user ID)
audAudienceWho the token is intended for
expExpirationWhen the token expires (Unix time)
iatIssued AtWhen the token was created
nbfNot BeforeToken not valid before this time
jtiJWT IDUnique identifier for this token
Decode ≠ Verify

This tool decodes the token but doesn't verify the signature. Signature verification requires the secret key, which should never be shared. Always verify signatures server-side.

Real-World Use Cases

1. The Expired Token Mystery

Context: Users report being logged out randomly. No pattern you can identify.

Problem: The API returns 401 but doesn't explain why.

Solution: Decode the failing token. See exp claim shows it expired 30 seconds ago. Token refresh logic has a race condition.

Outcome: Fix the refresh timing. Add buffer before expiration. No more random logouts.

2. The Missing Permission

Context: Admin user can't access admin endpoints. Frontend shows admin role.

Problem: Backend returns 403 Forbidden on admin-only routes.

Solution: Decode the JWT. The roles claim shows ["user"] not ["admin"]. Token was issued before role was added.

Outcome: User logs out and back in. New token includes admin role. Access granted.

3. The Wrong Audience

Context: Microservice A's token gets rejected by Microservice B.

Problem: Both services use the same auth provider but tokens fail cross-service.

Solution: Decode reveals aud: "service-a". Service B expects aud: "service-b".

Outcome: Configure auth to include both audiences, or use separate tokens per service.

4. The Clock Skew Issue

Context: Newly issued tokens are immediately rejected as "not yet valid".

Problem: Token creation server has different time than validation server.

Solution: Decode shows nbf (not before) is 2 minutes in the future. Server clock drift.

Outcome: Sync server clocks with NTP. Add 30-second tolerance for clock skew.

5. The Data Leak Audit

Context: Security review of authentication implementation.

Problem: Need to verify JWTs don't contain sensitive PII that shouldn't be exposed.

Solution: Decode production tokens. Find they include full email, phone, and address—excessive data.

Outcome: Reduce claims to minimum necessary (user ID only). Fetch profile data when needed.

6. The Algorithm Confusion

Context: JWT verification fails with "invalid signature" in production but works locally.

Problem: Same code, same secret, different results.

Solution: Decode shows production token uses RS256 (RSA) but code expects HS256 (HMAC).

Outcome: Update verification to handle the correct algorithm. Never auto-detect algorithm (security risk).

7. The Session Debugging

Context: User reports seeing another user's data after login.

Problem: Catastrophic—possible authentication bypass.

Solution: Decode both users' tokens. Find sub claim shows same user ID. Token cache returning wrong user's token.

Outcome: Fix caching key to include user identifier. Clear cache. Crisis resolved.

Common Mistakes and How to Avoid Them

JWTs Have Gotchas

JWTs are simple in concept but have subtle security implications. Many breaches stem from JWT misuse, not implementation bugs.

Storing Sensitive Data in JWTs
❌ The Mistake
Putting passwords, credit card numbers, or other secrets in JWT payloads because "they're encoded."
âś… The Fix
JWTs are not encrypted—anyone can decode them. Store only non-sensitive identifiers. Put sensitive data in a secure database.
Not Validating the Algorithm
❌ The Mistake
Accepting any algorithm the token claims to use, including `none` which has no signature.
âś… The Fix
Always validate tokens with explicit algorithm expectations. Never accept 'none' or allow algorithm switching from header.
Ignoring Token Expiration
❌ The Mistake
Decoding and using JWT data without checking if `exp` claim shows it's expired.
âś… The Fix
Always validate expiration. Most JWT libraries do this automatically—make sure it's not disabled.
Using JWTs for Sessions That Need Revocation
❌ The Mistake
Using long-lived JWTs for sessions where you need ability to force logout (fired employee, compromised account).
âś… The Fix
JWTs can't be revoked once issued. Use short-lived tokens with refresh, or maintain a revocation list for critical systems.
Passing JWTs in URL Parameters
❌ The Mistake
Putting tokens in URLs like `?token=eyJ...` where they get logged by servers, proxies, and browser history.
âś… The Fix
Pass JWTs in Authorization headers (Bearer token) or secure HTTP-only cookies. Never in URLs.

Privacy and Data Handling

This JWT Decoder operates entirely in your browser. Your tokens stay private.

  • No tokens are sent to any server.
  • No data is logged or stored.
  • No account required.
  • Works completely offline.

Feel safe decoding production tokens—they never leave your device.

Conclusion

JWTs are the foundation of modern authentication, but they're opaque by design. When auth fails, you need to see what's inside the token—quickly.

This decoder transforms cryptic base64 strings into readable JSON in seconds. Check expiration times, verify claims, debug auth flows, and audit token contents without writing code or installing tools.

Authentication debugging shouldn't require a decoder ring. Now it doesn't.

Frequently Asked Questions