JWT Expiration Decoder

Decode JWT expiration without a library

A JSON Web Token (JWT) packs claims into three Base64url segments separated by dots: header, payload, and signature. Time-related claims live in the payload as Unix seconds — not milliseconds. When you paste a token into this page, UnixLi only decodes the header and payload so you can read exp, iat, and nbf instantly. Nothing is uploaded; decoding stays inside your browser tab.

Example: Unix timestamp 1715429912 is Saturday, May 11, 2024 at 12:18:32 UTC. If a JWT exp equals that value, the token expired at that exact UTC instant, regardless of the viewer’s local timezone.

What JWT exp, iat, and nbf mean

The JWT profile (RFC 7519) defines registered claim names for time:

• iat (Issued At) — when the token was created, as NumericDate Unix seconds.
• nbf (Not Before) — the earliest moment the token should be accepted. Before this second, validators should reject it.
• exp (Expiration Time) — the last moment the token remains valid. After this second, it is expired.

All three use the same unit: seconds since 1970-01-01T00:00:00Z. Comparing them to “now” is therefore a simple integer comparison once both sides are in Unix seconds. This tool highlights expiration status by comparing exp (and optionally nbf) against your local clock converted to UTC seconds.

How to decode a JWT payload without a library

You do not need a JWT library to inspect claims. Split the string on ., take the second segment, convert Base64url to standard Base64, then decode and parse JSON. Signature verification is a separate step that requires the secret or public key — this page never claims to verify signatures; it only shows what the payload says.

JavaScript (inspect only):

const [, payload] = token.split('.');
const json = atob(payload.replace(/-/g,'+').replace(/_/g,'/').padEnd(Math.ceil(payload.length/4)*4,'='));
const claims = JSON.parse(json);
// claims.exp → e.g. 1715429912 → 2024-05-11 12:18:32 UTC

Python (inspect only):

import base64, json
payload = token.split('.')[1]
pad = '=' * (-len(payload) % 4)
claims = json.loads(base64.urlsafe_b64decode(payload + pad))
print(claims.get('exp'))  # Unix seconds

In production, prefer battle-tested libraries (jose, jsonwebtoken, PyJWT) that verify the signature, check alg, and enforce clock skew. Use UnixLi when you need a fast, private look at expiration while debugging logs or support tickets.

Common JWT timestamp bugs

• Seconds vs milliseconds. Specs require seconds. Writing Date.now() (ms) into exp produces a 13-digit value that looks like a date far in the future when treated as seconds — or 1970 when wrongly scaled the other way.
• Timezone display confusion. Claims are always UTC seconds. Showing them in local time without labeling UTC misleads readers in other zones.
• Clock skew. Distributed systems often allow a small leeway (e.g. 30–60 seconds) when comparing exp/nbf to “now.” A token that looks “barely expired” on one machine may still be accepted on another.
• Missing exp. Some tokens omit expiration. That is a security smell for session-like JWTs; inspect deliberately rather than assuming forever-valid.

When to use this tool vs libraries

Use UnixLi JWT Decoder to paste a token from DevTools, an email, or a log line and see human-readable iat/nbf/exp without installing anything. Privacy matters: 100% in-browser processing means the JWT never leaves your tab — ideal for production tokens you should not paste into random online “JWT debugger” backends.

Use jose / jsonwebtoken / PyJWT inside applications to verify signatures, restrict algorithms, validate audiences, and reject tampered tokens. Decoding alone is never authentication.

Prefer our deeper guide: How to decode JWT expiration without a library. Also see the universal Unix timestamp parser, JavaScript timestamp snippets, and Python timestamp helpers.

Frequently asked questions

Related tools