How to Read JWT Expiration Time with a JWT Decoder

How to Read JWT Expiration Time with a JWT Decoder

JWT failures often look like "auth is broken" when the real issue is narrower: the token expired, the token is not valid yet, or two systems disagree about what time it is. If you can read the time claims quickly, most of the confusion gets smaller fast.

A %%BLOGTOKEN0%% workflow is useful for exactly that first step. It lets you inspect the header and payload immediately, then decide whether the problem is expiration, audience, issuer, algorithm choice, or verification context.

The Three Time Claims That Matter Most

%%BLOGTOKEN0%%

%%BLOGTOKEN0%% is the expiration time. After this moment, the token should be rejected.

%%BLOGTOKEN0%%

%%BLOGTOKEN0%% is the issued-at time. It tells you when the token was minted.

%%BLOGTOKEN0%%

%%BLOGTOKEN0%% means "not before." If the current time is earlier than this value, the token may decode fine but still fail validation.

Reading these claims together is better than checking %%BLOGTOKEN0%% alone. A token can appear "fresh" until you realize %%BLOGTOKEN1%% is in the future or %%BLOGTOKEN2%% is far outside the expected session window.

The Fastest Debugging Workflow

1. Open the %%BLOGTOKEN0%%.
2. Paste the token exactly as it was captured.
3. Read the header first for %%BLOGTOKEN0%% and token shape.
4. Read the payload for %%BLOGTOKEN0%%, %%BLOGTOKEN1%%, %%BLOGTOKEN2%%, %%BLOGTOKEN3%%, and %%BLOGTOKEN4%%.
5. Convert the numeric time claims with the %%BLOGTOKEN0%%.
6. Compare those values with the time the request actually failed.

That order helps because a readable token does not mean a trusted token. You want visibility first, then verification in the application context.

Seconds vs Milliseconds

This is one of the easiest ways to misread JWT time claims.

• Standard JWT time claims are usually Unix seconds.
• Many frontend logs, analytics systems, and JavaScript helpers use milliseconds.

If a value is 13 digits long, treat it as a warning sign that you might be looking at milliseconds rather than seconds.

For example:

1710000000     -> likely seconds
1710000000000  -> likely milliseconds

If you compare the wrong unit with your request logs, the token can look expired by decades or valid far into the future.

Clock Skew And Timezone Confusion

Timezone does not usually change the stored instant, but it changes how humans talk about the event. That creates confusion fast in debugging threads.

Typical failure pattern:

• the identity provider minted the token in UTC
• the browser or app logs display local time
• someone compares the two without converting them
• the team concludes the token expired "early"

Clock skew makes this worse. Even small differences between servers, clients, proxies, and identity systems can flip a token from valid to invalid right on a boundary.

If the failure sits near a claim boundary, assume skew is possible until you rule it out.

What A Decoder Can And Cannot Tell You

Useful answers you can get immediately

• what algorithm the token claims to use
• whether %%BLOGTOKEN0%%, %%BLOGTOKEN1%%, and %%BLOGTOKEN2%% are present
• whether issuer and audience look plausible
• whether the payload is obviously stale, future-dated, or malformed

Things the decoder does not prove

• that the signature is valid
• that the correct secret or public key was used
• that the issuer and audience are acceptable to your application
• that the token should be trusted just because it is readable

That distinction matters. Decoding is inspection. Verification is a separate security step.

A Practical Claim-Reading Example

Imagine a token payload like this:

{
  "iss": "https://auth.example.com",
  "aud": "web-app",
  "iat": 1710000000,
  "nbf": 1710000000,
  "exp": 1710003600
}

That token has a one-hour lifetime. If a request fails at 1710003900, the token is already expired. If the request fails at 1709999900, the token may not be valid yet. If the request fails near either edge, check clock skew before assuming the identity provider or app code is wrong.

Common Auth-Debugging Mistakes

• checking only %%BLOGTOKEN0%% and ignoring %%BLOGTOKEN1%%
• comparing JWT seconds with log timestamps recorded in milliseconds
• trusting a decoded payload without verifying the signature
• ignoring %%BLOGTOKEN0%% and %%BLOGTOKEN1%% when the token "looks fine"
• discussing local times in chat without converting them back to a shared timezone

Related Workflows

• Use the %%BLOGTOKEN0%% for local token inspection.
• Use the %%BLOGTOKEN0%% when the numbers need human-readable review.
• If the issue is broader claim inspection, not just expiry, continue with the decoder before changing code or auth configuration.

FAQ

Can a JWT decode cleanly and still be rejected?

Yes. Readable payloads are common even when the signature is wrong, the token is expired, the audience mismatches, or the issuer is not trusted.

Should I paste production tokens into any decoder?

Only if the tool clearly explains that decoding happens locally and no token is uploaded. This site's %%BLOGTOKEN0%% runs in the browser.

Why does the token look valid in one system and expired in another?

The usual causes are clock skew, timezone confusion in the human discussion, or seconds-versus-milliseconds mistakes in one part of the workflow.

Conclusion

Most JWT expiration debugging gets easier once the time claims stop being opaque numbers. Decode the token, read %%BLOGTOKEN0%%, %%BLOGTOKEN1%%, and %%BLOGTOKEN2%% together, convert the values, and compare them with the failure window before assuming the whole auth stack is broken.

Use the %%BLOGTOKEN0%% first, then the %%BLOGTOKEN1%% when you need to reason about the exact moments behind the claims.