How to Decode a JWT Token (Header, Payload, Signature)

A JWT (JSON Web Token) is a compact, Base64URL-encoded string used to carry claims between two parties, most commonly for authentication in web APIs. A JWT has three parts — header.payload.signature — separated by dots, and the first two can be decoded to readable JSON without any secret. The NeatForge JWT Decoder decodes the header and payload locally in your browser and highlights time-based claims.

What Is a JWT?

A JWT encodes a JSON object (the “claims”) into a string that can be safely passed in URLs, headers or cookies. A typical token looks like:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE3MDAwODY0MDB9.s8vN...signature

JWTs are stateless: the server does not need to look up a session, because the claims travel inside the token itself.

The Three Parts of a JWT

• Header — describes the token type and signing algorithm (e.g. {"alg":"HS256","typ":"JWT"}).
• Payload — contains the claims, such as user ID, roles, and timestamps.
• Signature — used to verify that the token was not tampered with.

Only the header and payload can be decoded — the signature is not JSON and cannot be “decoded”, only verified.

The header and payload are encoded with Base64URL, a variant of Base64 that uses - instead of +, _ instead of /, and omits = padding so the string is safe in URLs. For a deeper look at that encoding, see our guide on how to encode and decode Base64.

What iat, nbf and exp Mean

These three registered claims are stored as Unix timestamps in seconds:

• iat (issued at) — when the token was created.
• nbf (not before) — the earliest time the token is valid.
• exp (expiration) — when the token stops being valid.

A token is active only when the current time is between nbf and exp. The decoder compares these timestamps to your browser’s clock and flags expired or not-yet-valid tokens in red or yellow.

Decode vs Verify — An Important Distinction

Decoding only reverses the Base64URL encoding so you can read the claims. Anyone can decode a JWT, and anyone can forge a token with arbitrary claims.

Verification checks the signature against the signing secret or public key to confirm the token was issued by a trusted party and has not been modified.

This tool decodes only. It does not verify the signature. Never trust a decoded token’s claims for access control without verifying it server-side first.

How to Decode a JWT Safely

1. Open the JWT Decoder.
2. Paste the token into the input box.
3. Review the pretty-printed header and payload JSON.
4. Check the color-coded status of iat, nbf and exp.

Privacy Note

Decoding happens entirely in your browser. Your token is never uploaded, logged, or stored. Even so, avoid pasting highly sensitive tokens into third-party sites, and never share JWTs in screenshots or support tickets — they may contain user IDs or scopes.

Claims You Will Meet Beyond iat, nbf and exp

Real-world tokens carry far more than timestamps. These five claims appear in the majority of production JWTs:

• iss (issuer) — who created the token, typically a URL like https://auth.example.com. Your API should accept only issuers it trusts.
• sub (subject) — who the token is about, usually a user or account ID such as user_123. This is the value your backend uses to load the right record.
• aud (audience) — who the token is for, such as your application ID. A token minted for one app must be rejected by another, which is exactly what aud enforces.
• jti (JWT ID) — a unique identifier per token, used to build revocation lists and to detect replayed tokens.
• scope, roles or permissions — custom claims describing what the holder may do, for example read:orders or an array like ["admin", "billing"].

A typical decoded payload looks like this:

{
  "iss": "https://auth.example.com",
  "sub": "user_123",
  "aud": "my-app",
  "iat": 1700000000,
  "exp": 1700003600,
  "scope": "read:orders write:orders"
}

Notice that exp minus iat equals 3600, so this is a one-hour access token — the standard lifetime for tokens that travel with every API call. Refresh tokens live much longer (days or weeks) and are stored separately, precisely because a stolen hour-long token stops working on its own.

Troubleshooting Tokens That Fail

Count the dots. A valid JWT has exactly two dots separating three segments. Pasted tokens most often break because a line wrap, an ellipsis added by a log viewer, or a truncated chat message ate the tail of the signature. If you count fewer than two dots, re-copy from the source.

Check seconds versus milliseconds. If exp shows a date tens of thousands of years in the future, the issuer emitted milliseconds instead of seconds. A 13-digit value like 1700000000000 divided by 1000 gives the correct 10-digit seconds value. Paste any suspicious timestamp into the Timestamp Converter to see the human-readable date instantly.

Allow for clock skew. A “not yet valid” warning on a freshly minted token usually means the issuing server runs seconds or minutes ahead of your machine. Backend libraries handle this with a leeway setting, commonly 30 to 60 seconds, applied to both nbf and exp. If you control the validation code, add the leeway rather than demanding perfect clock sync across machines.

Suspect the wrong segment. Developers sometimes paste only the payload segment or an adjacent API key instead of the full token. Each segment alone is valid Base64URL, so a Base64 decoder may happily decode it while the JWT decoder complains. Always start your copy from the first character of the header segment and end at the last character of the signature.

FAQ

Does this tool verify the JWT signature? No. It only decodes the token. Verification requires the signing secret or public key and must be done server-side.

What do iat, nbf and exp mean? iat is issued-at, nbf is not-before, and exp is expiration. All are Unix timestamps in seconds.

Is it safe to paste my JWT here? Yes — all decoding is local and nothing is sent to a server. However, you should still avoid pasting tokens into untrusted sites.

→ Open the free JWT Decoder