Check JWT Header, Payload, and time Claims
Paste a JWT to parse its Header and Payload in the browser and compare exp, nbf, and iat with device time. Signatures are not verified.
Parse a JWTConclusion: Convert exp as a NumericDate in seconds and compare it with the verifier's current time
If exp=1893456000, it is 1893456000 seconds after 1970-01-01T00:00:00Z. JWT Decoder displays ISO 8601, local time, and relative time, and provides supplementary indication of whether it is valid or expired using the device clock.
The server accepts tokens in production. Do not determine validity from device display alone; also check server UTC, clock tolerance, signature, iss, and aud.
Do not share the Original Token; use a Dummy Token to verify the procedure.
Check the unit and boundary conditions of exp
RFC 7519 exp is a NumericDate in seconds since the Epoch. During validation, it must not be accepted when the current time is equal to or greater than exp. Whether to allow a small Clock Skew must follow the Library and Security Policy.
If exp does not exist, it means “no expiration claim”; the tool alone cannot determine whether it is permanently valid or always invalid.
| Account to check | What to check | judgment |
|---|---|---|
| Raw exp | Finite Number | Check whether it is seconds |
| UTC / Local | Same Instant | Distinguish TimeZone differences |
| Current | Validation time | Comparison with exp |
| Tolerance | 0–300 seconds | Matches the Policy |
Steps for entering and checking with JWT Decoder
- Parse the Token.
- Check the raw exp value in the claims table.
- Compare ISO, Local, and relative times.
- Record the indication that the device time is within the validity period together with unverified signature status.
"Within the validity period according to the device clock" does not mean verification succeeded.
Check the header, payload, and time claims in order
Read alg, typ, and kid in the header, and check iss, sub, aud, exp, nbf, iat, jti, and custom claims in the payload. aud may be an array rather than only a string, and do not infer permissions from only the names or values of custom claims. The presence of a signature segment does not mean its validity has been verified.
| Item | meaning | Precautions when checking |
|---|---|---|
| exp | Expiration Time | NumericDate seconds. It must not be accepted after expiration. |
| nbf | Not Before | Must not be accepted before this time |
| iat | Issued At | Issued time. Does not guarantee validity on its own. |
| iss / aud / sub | Issuer, recipient, and subject | Compare separately with the value expected by the verifier |
| alg / kid / typ | Algorithm, key ID, and type | Do not determine keys or Algorithms based only on declarations inside the Token |
Isolation if the problem persists
If the date and time is extremely far in the future or past, check seconds versus milliseconds, String versus Number, and timezone display.
If an API reports expiration, prioritize the server clock that evaluated the token and log timestamps; do not determine clock skew from the client's appearance alone.
- Whether it has about 10 digits of seconds
- Check whether Date.now() is inserted directly
- Have you checked Server UTC?
- Check that Refresh Token and Access Token are not confused.
Supported scope of the current JWT Decoder
DevelopTools' JWT Decoder does not send input tokens to a server; it parses the three segments of Compact JWS format in the browser. It removes the Bearer prefix and display line breaks, decodes the header and payload from Base64URL to UTF-8, and displays them as JSON objects. It can check signature presence, byte length, and segment strings, but does not verify signatures using keys.
| Account to check | Current tool operation |
|---|---|
| Input | Analyze Raw Tokens, Bearer Tokens, and wrapped Tokens. |
| structure | Separate the three Header.Payload.Signature segments, and display five-segment JWE as unsupported |
| Decode | Handle Base64URL - and _, omitted padding, and inspect UTF-8 and JSON objects. |
| Claims | Display iss, sub, aud, exp, nbf, iat, and jti with their values and explanations |
| time | Display exp, nbf, and iat as ISO 8601, the user's local time, and relative time from now |
| Determine | Provide supplementary display for expiration, before-validity, future iat, and similar states based on device time and allowed clock-skew seconds |
| output | Copy Token, formatted Header, and formatted Payload to the Clipboard |
Signature verification for HS256, RS256, and similar algorithms; loading private keys, public keys, JWK, and JWKS; validation of expected issuer and audience values; revocation, scope, and permission checks; and JWE decryption are not performed. Displaying “within the validity period according to the device clock” also does not guarantee that the entire token is valid or safe.
Treat decode, verify, and validate separately
Decode converts Base64URL representation into a readable form. Verify checks that a token has not been tampered with using its signature, a trusted key, and an allowed algorithm. Validate additionally compares exp / nbf, issuer, audience, purpose, revocation state, and more against application policy. Successful decoding does not mean verification or validation has succeeded.
In a typical three-segment JWS, the header and payload are not encrypted. Anyone who obtains the token can read its contents, so do not put passwords, secrets, or unnecessary personal information in the payload. Do not post real tokens in articles, issues, chats, URL queries, or screenshots; use dummy tokens for verification.
The current tool display is not signature-verified. Do not use it for authentication, authorization, final decisions about production incidents, or guarantees of token safety; validate with the official procedure for your authentication library and identity provider.
Verify JWT and JOSE specifications using primary sources
Use RFC 7519 for claims and NumericDate, RFC 7515 for JWS Compact Serialization and Base64URL, RFC 7516 for JWE, RFC 4648 for the Base64URL alphabet, and RFC 8725 for JWT Security Best Current Practice. Check RFC 6750 for how to use bearer tokens.
Example: compare exp in UTC and Japan time
Parse exp in a dummy payload and display ISO 8601 alongside browser local time.
The same instant is displayed in different timezone notations, and you can check the remaining or elapsed time from now.
- Parse a dummy JWT
- Record the raw exp value
- Compare ISO and local time
- Try a new token immediately before and after the boundary time
Do not paste production token values into articles or bug reports; if necessary, safely transcribe only the date and time.
Frequently asked questions
- Is a Token valid if its JWT can be decoded?
- No. Decode reads the contents. Whether it can be used for authentication depends on signature verification with a trusted key, allowed Algorithms, validation of iss, aud, exp, nbf, and more, as well as revocation and Application Policy.
- Is a JWT Payload encrypted?
- A typical 3-segment JWS is not encrypted; it is only represented in Base64URL. Do not treat it as a place to store confidential information.