JWT exp Before iat – Fix Expiration Earlier Than Issued At

Local only

Troubleshoot a token whose numeric expiration precedes its issued-at timestamp.

113 chars · 1 line

141 chars · 11 lines

Algorithm: HS256Signature not verifiedTime status: Active by exp/nbfIssued in future: 2030-03-17T17:46:40.000ZExpires: 2027-01-15T08:00:00.000Z

JWT claim chronology issue

How to diagnose a JWT where exp is earlier than iat

Both iat and exp can be individually valid NumericDate numbers while still contradicting each other. The decoder formats each available timestamp, but it does not perform cross-claim policy validation, so the inconsistent chronology remains something the issuer or verifier must detect. This tool is free to use. No account or payment is required.

Last updated

What you can do here

  • Browser-local JWT decoding
  • Strict three-segment validation
  • Canonical Base64URL checks
  • Header and payload JSON validation
  • Expiration status details
  • No signature verification claims

Steps

  1. Decode and compare the Issued and Expires or Expired timestamps.
  2. Inspect the raw iat and exp numeric values for swapped fields or unit mistakes.
  3. Fix token construction and reissue the token rather than modifying an existing signed payload.

Cross-claim consistency is separate from JSON decoding

The decoder can faithfully display both timestamps without deciding whether their relationship is acceptable. Authentication libraries and issuer policy should validate required chronology and lifetime rules.

Expiration before issuance

The payload places exp at 1800000000 and iat at 1900000000.

Claims

"iat":1900000000, "exp":1800000000

Chronology

exp occurs before iat

Common questions

Frequently asked questions

Why does the JWT still decode?

Both claims are valid JSON numbers and valid individual dates. Their relationship is a validation concern, not a decoding failure.

Could the fields simply be swapped?

Yes. Compare token-generation code and expected lifetime calculations at the issuer.

Does this page verify the token lifetime policy?

No. It exposes the claims locally; trusted verification remains application-specific.

Recommended next steps

JWT iat in the FutureInspect a future issued-at timestamp without confusing decoding with policy validation.JWT Expired TokenDecode an exp claim and understand the decoder's Expired status.Unix Timestamp Converter OnlineConvert iat and exp NumericDate values to readable UTC timestamps.

Debugging a specific JWT issue? Browse JWT troubleshooting.