Hashes, IDs, and randomness
Inspect JWT contents and expiration claims
Tools to use
A 401 response invites suspicion about expiration, but a future timestamp inside a JWT does not prove the server is wrong. Expiration is only one check; signatures, issuer and audience are separate conditions. We will use an invented token to understand the timestamps without exposing real authentication credentials.
Three parts separated by two dots
Paste the following into JWT decode. Two dots separate Header, Payload and Signature. This demonstration uses alg none and an empty signature; it is not a login credential. The tool decodes Base64url JSON but does not treat a successfully parsed token as trusted.
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJkZW1vLXVzZXIiLCJpYXQiOjE3MDQwNjcyMDAsIm5iZiI6MTcwNDA2NzIwMCwiZXhwIjoxNzA0MDcwODAwfQ.Real JWTs may contain identifiers and permissions. Base64url is not encryption, so a signed payload can still be read. Reading a token and modifying it so a verifier accepts it are different abilities. Signature verification addresses the latter, and this decoder does not perform it.
What exp, nbf and iat each mean
iat and nbf are 1704067200: 2024-01-01 00:00:00 UTC. exp is 1704070800: one hour later. iat describes issuance, nbf the not-before boundary, and exp expiration. An issuance claim does not imply a universal one-hour lifetime; that interval belongs only to this example.
iat = nbf = 2024-01-01T00:00:00Z
exp = 2024-01-01T01:00:00ZJWT NumericDate is based on Unix seconds. Putting Date.now() milliseconds directly into exp changes its meaning. Verify the producer's unit, then use Unix-time conversion with seconds explicitly selected. A JSON string containing a date is not the same as a numeric claim; this tool's time interpretation applies to numeric claims.
Your device clock is not the verifier's clock
The tool compares claims with the device's current time as a reference. At exp itself, it is on the expired side. It cannot know the server's clock, permitted clock skew or authentication-library configuration. A slow device may show a future expiration already passed by the server.
'It is still today locally' is insufficient: 01:00 UTC and 10:00 Japan time represent the same instant. Changing the display zone does not extend a token's life. Report UTC or an explicit offset and distinguish device observations from server logs. This tool does not query the server's clock.
Editing the expiration does not repair authentication
Changing exp and re-encoding the payload can make a decoder display a future date. For a signed JWT, however, that changes signed content and invalidates the original signature. Authentication requires proper verification. Neither successful decoding nor a future timestamp establishes successful authentication; the unverified warning preserves this distinction.
Displayed iss and aud do not prove issuance or that the current API is the intended audience. alg is input data, not a trusted configuration. The tool fetches no keys and contacts no authentication server. Continue with verifier configuration and logs, sharing only necessary identifiers and timestamps rather than whole credentials.
Do not force unrelated token formats into JWT
This screen handles three-part JWTs, not five-part encrypted JWE or opaque service tokens. Removing separators or characters until parsing succeeds no longer examines the original. Check the copied range, surrounding quotes and an Authorization header's Bearer prefix, then inspect only the actual token.
Finish with a precise observation: exp in UTC, its relation to the device clock, and signature not verified here. Do not invent absent claims. Even without automatic storage, screen sharing, screenshots and clipboards can expose credentials. Practice with this fictional example and follow your organization's handling rules for real data.
An admin claim is not proof of authorization
A payload's role or userId can look authoritative, but this screen only reads claims. It does not establish issuer, intended audience, valid signature or current authorization. A future exp substitutes for none of those checks. Use decoded claims as debugging evidence, not as a reason to grant access.
First establish which token the failed request actually used. A different token copied from an earlier screen with a future exp does not disprove expiry in the failed request. Align the token and relevant client/server times. If examining a real credential, also consider screen sharing and clipboard exposure; use sanitized examples in public bug reports.
Report facts narrowly: exp is past relative to this device, nbf appears future, or the input cannot be parsed as three parts. Avoid 'valid JWT,' which implies verification beyond decoding. Editing a timestamp into a readable payload does not repair the originally signed token or establish that authentication will accept it.