Two different teams can both say “the token is fine” and still be correct on their own terms. One team decoded the JWT payload and read exp. The other team verified the signature with issuer keys and revocation rules. Expiry is only trustworthy after verification, but expiry is still useful for debugging when you already trust the transport or you are chasing clock skew.
What JWT expiry actually means in UTC
Most web stacks store exp as numeric seconds since epoch. That is the same time axis logs use, which is why pairing JWT work with the Unix timestamp converter keeps postmortems honest. The JWT expiry checker reads exp and compares it to “now” in the browser so you can answer “should this still be valid?” without opening three tabs. It does not verify signatures. Verification still belongs to your auth service and your keys.
Skew matters. A laptop set five minutes fast makes good tokens look expired. A container set to UTC while humans think in local wall time creates “ghost expiries” in screenshots. Write down the clock source when you file incidents.
Decode vs verify: keep the vocabulary strict
Decoding answers “what JSON claims are inside?” Verifying answers “did the issuer I trust actually sign this?” Anyone can Base64URL-decode a blob. Only your platform can validate signatures and policies. Read the full mental model in the JWT decode vs verify guide and use the JWT decoder when you need header and payload JSON, not only the expiry line.
API health checks: curl beats the browser for internal URLs
Browsers enforce CORS. Terminals usually do not. When you paste a staging health URL, you want a command you can run from a bastion or CI debug shell. The API URL checker validates scheme and host and prints a suggested curl -I line. It intentionally avoids async fetches inside the synchronous calculator so results stay deterministic in tests. Treat live status codes as a second step, not a missing feature.
Comparison: which question each tool answers
| Question | Tool |
|---|---|
| What claims are inside? | JWT decoder |
| Is exp in the past relative to this laptop clock? | JWT expiry checker |
| What is 1735689600 in UTC? | Unix timestamp converter |
| Is this URL well formed for a probe? | API URL checker |
Common mistakes in JWT incidents
- Treating decoded payloads as proof of authenticity.
- Ignoring leeway configuration on verification while reading raw exp.
- Pasting refresh tokens into public threads.
- Mixing milliseconds and seconds without checking digit length.
- Assuming browser network panels show the same TLS path as server-to-server calls.
When to use these tools on Toollabz
- When support asks “did this session expire yet?” and you need a fast clock-relative answer.
- When writing runbooks that should include copy-pasteable curl probes.
- When correlating webhook logs with token issuance timelines.
Continue with encoding topics in Base64, URLs, and JWT fragments and keep JSON hygiene in JSON formatting and validation explained.