JWT Decoder Guide

Best for

Best for decoding JWT headers and payloads, checking exp, iat, and nbf claims, reviewing issuer and audience values, and debugging token-related API responses.

Not for

Not for verifying signatures, validating token trust, storing production secrets, or proving that a token is safe to accept.

Common debugging workflow

Decode the token locally, review header and payload JSON, convert time claims with Timestamp Converter, then compare issuer, audience, roles, and scopes against your auth provider settings.

How to use this tool

1. Paste a JWT with three dot-separated segments.
2. Decode the Base64URL header and payload locally.
3. Inspect claims such as sub, iss, aud, iat, and exp.

Real examples

• Read the alg and typ fields from a token header.
• Check whether an exp timestamp has already passed.
• Decode a token payload, then format the JSON for review.

Common use cases

• Debug OAuth and OpenID Connect access tokens.
• Inspect claims returned from a local API test.
• Confirm whether a token is malformed before checking server logs.

exp and iat timestamps

JWT exp, iat, and nbf claims are usually Unix seconds. Convert them to readable UTC and local time before assuming a token is expired or not yet valid.

Decode is not verify

Decoding only reads the header and payload. A token can still be forged, expired, unsigned, or signed with the wrong key until your application verifies the signature and claims.

Base64URL JWT segments

JWT uses Base64URL encoding, where - and _ replace URL-sensitive characters and padding may be omitted. This page normalizes those segments before parsing JSON.

OAuth debugging workflow

Inspect iss, aud, scopes, roles, and time claims locally, then compare the decoded JSON with expected app settings before checking provider logs.

Sample input/output

• Input: header.payload.signature.
• Header: JSON with alg and typ.
• Payload: readable JSON claims and timestamp labels.

Common errors and fixes

• Token has fewer than 3 segments: JWTs usually have header.payload.signature; check that the full token was copied.
• Payload decodes but the API still rejects it: decoding is not verification; check signature, issuer, audience, and expiry in your auth system.
• exp looks like a random number: send the value to Timestamp Converter to read it as Unix seconds.

Edge cases table

Edge cases / errors

• Opaque tokens cannot be decoded as JWTs.
• Some JWTs omit optional claims such as aud or iss.
• Never paste production secrets into tools you do not trust.

Related workflow

• Convert exp and iat values with Timestamp Converter.
• Decode JWT-like Base64URL segments with Base64 Encoder / Decoder.
• Parse OAuth callback URLs with URL Query Parser.

Claims to inspect first

Expired token workflow

Decode the payload, copy exp, and open Timestamp Converter. If the value looks thousands of years off, you may be treating Unix seconds as JavaScript milliseconds.

Audience and issuer mismatch

Many authorization failures are not parsing failures. After decoding, compare iss and aud with your API configuration before changing application code.

Safe sharing practice

For bug reports, copy only the claim names or a redacted payload shape. Do not paste real bearer tokens, signatures, customer identifiers, or provider secrets into public tickets.

The exp claim — expiration time

exp is the moment the token stops being valid, e.g. "exp": 1716239022. Decode the payload, copy the value into the Timestamp Converter, and compare it with the current time: if exp is in the past, the token is expired and the API is right to reject it. If the date lands thousands of years in the future, milliseconds were used where seconds belong — the most common exp bug. A readable, unexpired exp says nothing about authenticity; signature verification belongs in your auth library, not in a decoder.

The iat claim — issued-at time

iat records when the token was created. Comparing iat with exp shows the intended token lifetime, which helps explain unexpected refresh behavior. An iat in the future almost always means clock skew between issuer and verifier, or a stale test fixture — check both clocks and the timestamp unit before changing application code.

The nbf claim — not before

nbf is the earliest moment the token may be accepted. A token can be simultaneously issued (iat passed) and still rejected because nbf has not arrived yet — another symptom that looks like a parsing bug but is really a clock or configuration question.

Does this upload my JWT?

No. The token is decoded locally in the browser.

Does this verify JWT signatures?

No. This tool decodes only. Signature verification requires the correct key and trusted runtime.

Why does expiration look wrong?

JWT timestamp claims use Unix seconds. JavaScript timestamps often use milliseconds.

Can I decode opaque tokens?

No. Opaque tokens are not JWTs and cannot be decoded into header and payload JSON.