How to Decode and Inspect JWT Tokens

What is a JWT Token?

A JSON Web Token (JWT) is a compact, self-contained string used to securely transmit information between systems. You will find them in Authorization headers, cookies, query parameters, and API responses across virtually every modern web application.

A JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNzE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The three dot-separated parts are:

1. Header — the algorithm used to sign the token and the token type (JWT)
2. Payload — the claims: user ID, roles, expiry time, and any custom data
3. Signature — a cryptographic signature that proves the token has not been tampered with

The header and payload are only Base64URL-encoded — not encrypted. Anyone who has the token can read them. The signature is what prevents forgery.

When Do You Need to Decode a JWT?

• Debugging an authentication flow — checking which claims are in the token
• Verifying the expiry time (exp claim) to understand why a user is being logged out
• Inspecting a token from a third-party provider (Auth0, Cognito, Firebase, etc.)
• Confirming that custom claims are being set correctly after a code change

Decoding a JWT — Step by Step

1. Open the JWT Decoder.
2. Paste your JWT token into the input area at the top.
3. The tool immediately displays the decoded Header and Payload in formatted JSON.
4. Check the claims — look for sub (user ID), exp (expiry), iss (issuer), and any custom fields your application uses.

No button to press, no server round-trip. Everything happens instantly in your browser.

Understanding the Decoded Output

Header

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

• alg — the signing algorithm. Common values: HS256, RS256, ES256, EdDSA
• typ — always JWT

Payload (Claims)

{
  "sub": "user_123",
  "name": "Alice",
  "email": "[email protected]",
  "role": "admin",
  "iat": 1716239022,
  "exp": 1716242622
}

| Claim | Meaning | |---|---| | sub | Subject — typically the user ID | | iss | Issuer — who issued the token | | aud | Audience — who the token is intended for | | exp | Expiry — Unix timestamp, after which the token is invalid | | iat | Issued at — when the token was created | | nbf | Not before — token is not valid before this timestamp |

Any other fields are custom claims added by your application.

Checking Expiry

The exp claim is a Unix timestamp (seconds since 1 January 1970 UTC). The JWT Decoder converts it to a human-readable date automatically so you can see at a glance whether the token has expired.

Verifying the Signature

Decoding the header and payload does not require the secret — they are just Base64URL encoded. To verify that the token was signed by a trusted party and has not been modified, you need the secret or public key.

1. Scroll to the Verify Signature section in the JWT Decoder.
2. Select the algorithm (must match the alg in the header).
3. For HMAC (HS256 / HS384 / HS512): paste your shared secret.
4. For RSA / EC / EdDSA: paste the PEM public key.
5. The tool shows Signature Verified ✓ or Invalid Signature ✗ immediately.

All verification runs via the browser's Web Crypto API — your keys are never transmitted anywhere.

The Three-Part Structure in Detail

Each part of a JWT is Base64URL-encoded. You can decode them manually:

// In any browser console
const [header, payload, signature] = token.split('.')
JSON.parse(atob(header.replace(/-/g, '+').replace(/_/g, '/')))
JSON.parse(atob(payload.replace(/-/g, '+').replace(/_/g, '/')))

The signature is binary and cannot be decoded to readable text — it can only be verified against the original header and payload using the signing key.

Common JWT Pitfalls

Token expired? Check the exp claim. Server time and client time must be synchronised. A difference of even 30 seconds can cause issues if your server has tight clock skew tolerance.

Wrong algorithm? If the alg in the header is RS256 but you are verifying with an HMAC secret, verification will fail. Always match the algorithm.

Missing claims? If your application expects a role or tenant claim that is not in the payload, the token was probably issued by an older version of your auth service.

none algorithm? A JWT with "alg": "none" has no signature. Never accept such tokens in production — they can be trivially forged.

Tips and Tricks

• Use the Base64 Decoder in URL-safe mode to manually decode individual JWT parts if you need to inspect raw bytes.
• When sharing a JWT for debugging, replace the signature part with [redacted] to prevent others from reusing a valid token.
• The JSON Formatter is handy for formatting the raw payload JSON after manual decoding.

Related Tools

• JWT Decoder — Decode and verify JWT tokens directly in your browser.
• JWT Encoder — Create and sign new JWT tokens with HS256, RS256, ES256, and more.
• Base64 Decoder — Decode Base64URL-encoded strings manually.