How to Decode a JWT and Check Its Expiration Time

A compact JSON Web Token often arrives as a long string that is difficult to inspect in a log, an API client, or a browser storage panel. Its first two segments hold a JSON header and a JSON claims set encoded with Base64URL. Decoding those segments turns an opaque value into fields you can read: an algorithm name in the header, an account subject in the payload, an intended audience, and perhaps an expiration time. That is especially useful when a frontend and API disagree about whether a session should still be active.

Time claims look simple until units and boundaries get mixed up. JWT NumericDate values count seconds from 1970-01-01T00:00:00Z, while JavaScript timestamps commonly use milliseconds. The `exp` claim sets the point at which the token must no longer be accepted, `nbf` sets the earliest usable time, and `iat` records when the token was issued. A useful decoder keeps those meanings separate, shows the original number, and renders a local date for convenience. It should also report which device time it used because an inaccurate clock can change a result near the boundary.

Remove an optional `Bearer` prefix, then split the compact value on dots. A normal input for this decoder has three segments. Validate each nonempty segment against the URL-safe Base64 alphabet, restore only the padding needed for decoding, and read the first two decoded byte sequences as strict UTF-8 JSON objects. The header must contain a nonempty `alg` string. In the payload, `iss`, `sub`, and `jti` should be strings; `aud` may be a string or an array of strings; and `exp`, `nbf`, and `iat` must be finite JSON numbers. Compare `now` with `exp` and `nbf` in seconds. RFC 7519 permits a small leeway for clock skew, so apply the same bounded tolerance to both sides of the window. Treat a future `iat` as a useful warning, not as the same rule as `nbf`.

RFC 7519 defines the JWT claims set and the registered `iss`, `sub`, `aud`, `exp`, `nbf`, `iat`, and `jti` claims. Its expiration rule requires the current time to remain before exp, its not-before rule requires the current time to reach nbf, and both permit a small leeway for clock skew. It defines NumericDate in seconds from the Unix epoch and describes iat as the issuance time. RFC 4648 defines the URL-safe Base64 alphabet used by compact JWT segments. The decoder follows those type and time rules while keeping application-specific claim decisions outside a generic result.

Suppose the device time is exactly `1,800,000,000`, the payload has `iat: 1,799,999,400`, `nbf: 1,799,999,970`, and `exp: 1,800,000,120`, and tolerance is zero. The token is inside its stated window because now is after nbf and still before exp. At `1,800,000,120`, the expiration result changes to expired. If you repeat the boundary check with a 60-second tolerance, expiration changes at `1,800,000,180`. That delay is intentional leeway, so the test report should record it. Now replace `exp` with the same digits stored as a JSON string. The date may look recognizable to a person, but its JSON type is wrong and the expiration claim must be reported as invalid.

With tolerance `L` seconds, the expiration check is `expired when now >= exp + L`. The not-before check is `not active when now + L < nbf`. A zero tolerance follows the exact NumericDate boundaries. The internal ordering should also make sense: `exp < iat` says the recorded expiration happened before issuance, and `exp < nbf` describes a window that closes before it opens. Missing `exp` is different from an invalid `exp`; the first has no expiration boundary to test, while the second supplies a value of the wrong type. These outcomes should remain distinct in both the status and the details.

A five-part value is usually an encrypted JWE and cannot be read by this decoder without the relevant decryption process. A two-part value, extra dots, invalid UTF-8, invalid JSON, an array where an object is expected, or mixed standard Base64 and Base64URL characters should fail with a specific input message. NumericDate can contain a fractional second, although many issuers use integers. Very large finite numbers may still fall outside JavaScript's date display range, so keep the raw claim visible even when no readable date can be produced. A missing `exp` does not erase other claims; decode the payload and state that no expiration boundary exists. Finally, issuer, audience, subject, revocation, session state, and maximum allowed age belong to the consuming application's own rules. Reading those claim values is useful, but a generic browser tool cannot decide whether they match a particular API configuration.

Confirm that the device clock is accurate, read NumericDate values as seconds rather than milliseconds, and compare issuer or audience values with the requirements of the application that consumes the token. Watch for one recurring error: treating iat as an automatic validity boundary, overlooking a missing exp claim, or adding an excessive tolerance that hides a genuine expiry problem.

Paste the compact value into TOOLFINA JWT Decoder & Expiration Checker. You may include the `Bearer` prefix copied from an Authorization field. Leave tolerance at zero for an exact boundary check, or enter a small value that matches the system you are testing. Select Decode and check expiration. Read the expiration card first, then inspect the header and payload JSON, the registered-claims table, and any time warnings. Each JSON panel has its own copy action; the result header can also copy or download both sections as one JSON file. Secondary counts sit in the status bars below the code. Expand the workspace when the payload is long.

Input: one compact JWT or Bearer value and an optional 0 to 300 second tolerance. Output: decoded and formatted header and payload objects, header metadata, exact registered-claim values, readable time values, expiration status, not-before status, future-issued warnings, claim-type errors, and impossible time-order warnings. Processing stays in the current browser. The tool does not fetch an issuer, contact an API, inspect server session state, or apply undocumented application rules.

The JWT is decoded and checked locally in the browser and is not uploaded, stored, or logged by TOOLFINA. The browser removes an optional Bearer prefix, validates the compact segments as unpadded Base64URL, decodes UTF-8 JSON objects, and compares NumericDate seconds with the current device time plus the selected tolerance.