JWT Decoder — Inspect Any JSON Web Token Instantly

JWTs are everywhere, but most developers treat them as black boxes

JSON Web Tokens show up in almost every modern web application. Your authentication header, your OAuth access token, your session cookie — there's a good chance at least one of these is a JWT. And yet many developers working with them daily have never actually looked inside one, relying on libraries to handle encoding and decoding without understanding what the token contains.

This creates real problems during debugging. An API returns 401. Is the token expired? Does it have the right claims? Is the audience wrong? Without opening the token, you're guessing. A JWT decoder gives you the answer in seconds.

---

What a JWT Actually Is

A JSON Web Token is a compact, URL-safe string representing claims between two parties. It has three parts separated by dots:

header.payload.signature

Each part is Base64URL-encoded. The decoder reverses this encoding to show you the raw JSON inside.

Header

Contains metadata about the token — typically the algorithm used to sign it and the token type:

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

Common algorithms: HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA). The algorithm tells you how the signature was generated and how it should be verified.

Payload

Contains the claims — statements about the user or entity and additional data. Standard claims:

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

Plus any custom claims your application adds — roles, permissions, user email, tenant ID, etc.

Signature

A cryptographic signature that verifies the header and payload haven't been tampered with. It's computed using the algorithm in the header and a secret (for HMAC) or private key (for RSA/ECDSA). The decoder shows you the signature but cannot verify it without the secret — verification requires the server.

---

How to Use the JWT Decoder on sadiqbd.com

1. Paste your JWT — the full token string, including all three dot-separated parts.
2. Read the decoded output — the tool splits the token and displays the header and payload as formatted JSON. It also shows the expiration time in human-readable format if an exp claim is present.
3. Check what you need — is the token expired? Does it have the right claims? Is the algorithm what you expected?

No secret or key is needed to decode — decoding just Base64URL-decodes the parts. Verification is a separate step your server handles.

---

Real-World Debugging Scenarios

Diagnosing a 401 Unauthorized

Your API is returning 401. You grab the Authorization header from the request and paste the token into the decoder.

Decoded payload:

{
  "sub": "user_1042",
  "iat": 1718000000,
  "exp": 1718003600,
  "roles": ["viewer"]
}

The current time is 1718010000 — the token expired at 1718003600. That's your 401. The client needs to refresh its token.

Checking for missing claims

Your API requires a tenant_id claim for multi-tenant routing. A partner reports their requests are failing. You decode their token:

{
  "sub": "partner_user_5",
  "iat": 1718000000,
  "exp": 1719000000
}

No tenant_id. Their auth server isn't including it. You have a specific, actionable answer instead of hours of log digging.

Verifying audience claim

An access token meant for your payments API is being sent to your notifications API. Your notifications API rejects it. Decoding reveals:

{
  "aud": "payments.yourapp.com",
  "sub": "user_201"
}

The aud claim doesn't include notifications.yourapp.com. The token was issued for the wrong service. This is correct behaviour — a properly configured API should reject tokens with wrong audience claims.

Understanding algorithm choices

You inherit a codebase and find JWTs being used. Decoding the header reveals:

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

This is a red flag — alg: none means no signature, no verification. Any payload can be accepted. This is a known JWT vulnerability. The decoder makes it immediately visible.

---

JWT Security Things Worth Knowing

Decoding is not verification. Anyone can decode a JWT — the payload is just Base64URL, not encrypted. Never put sensitive data in the payload (passwords, full credit card numbers, private keys) assuming it's hidden. It isn't.

The signature protects integrity, not confidentiality. The signature ensures the token wasn't tampered with. It doesn't hide the contents. If you need encrypted tokens, look at JWE (JSON Web Encryption), which is different from JWT.

alg: none is dangerous. Some early JWT libraries accepted tokens with alg: none as valid — meaning an attacker could forge any token by simply setting the algorithm to none and dropping the signature. Your JWT library should explicitly reject alg: none.

Short expiration + refresh tokens is the right pattern. Access tokens should expire quickly (15 minutes to 1 hour). A separate, longer-lived refresh token handles getting new access tokens. This limits the damage if an access token is compromised.

exp is a Unix timestamp. The decoder typically converts it to a human-readable date for you, but raw exp values like 1718003600 are seconds since January 1, 1970 UTC. You can cross-check against iat to see the token's intended lifetime.

---

Tips for Working With JWTs

Decode on every unfamiliar token. When integrating a new OAuth provider or auth service, always decode a sample token before writing code. Know what claims are present and their exact key names — documentation is often incomplete or out of date.

Check exp first when debugging auth failures. Token expiration is the most common cause of unexpected 401s. The decoder shows you the expiry in human-readable form immediately.

Validate audience in your API. If you have multiple APIs, every service should check that the aud claim matches its own identifier. This prevents token reuse across services.

Log decoded claims, not raw tokens. In application logs, logging the decoded user ID and roles is more useful than logging the raw token string. It's also less of a security risk — raw tokens can be replayed; a log entry showing user_id: 42, role: admin cannot.

---

Frequently Asked Questions

Can I use the decoder to verify a JWT signature? No — signature verification requires the secret or public key used to sign the token. The decoder shows you the contents without verifying. Verification happens on your server using a JWT library.

Is it safe to paste JWTs into an online decoder? For production tokens carrying real user sessions, use caution — treat a JWT like a password. For debugging in development or staging environments, online decoders are fine. Alternatively, use sadiqbd.com's tool and verify it doesn't log or store submitted tokens.

What's the difference between JWT and JWS? A JWT is the concept — a set of claims. A JWS (JSON Web Signature) is the signed representation most people call "a JWT." Technically, JWTs can also be encrypted (JWE), but signed JWTs (JWS) are what you encounter in 99% of auth systems.

Why is the payload Base64URL and not Base64? Base64URL replaces + with - and / with _, and omits padding =. This makes the token safe to include in URLs and HTTP headers without URL-encoding.

Is the JWT Decoder free? Yes — completely free, no sign-up required.

---

Most auth debugging sessions end faster once you can actually see what's in the token. Expiry, missing claims, wrong algorithm, wrong audience — the decoder surfaces all of these immediately. It's one of those tools that pays for itself the first time you use it.

Try the JWT Decoder free at sadiqbd.com — paste any JWT and see exactly what's inside.