Security · tokens
JWT expiry and cookie size.
Paste a token, or type exp and iat by hand, to get its lifetime, how much time is left and how many bytes it takes against the 4096-byte cookie limit. Nothing leaves this page.
Token and cookie
Result
Paste a token, or enter iat and exp, then press Calculate.
What the numbers mean
A JWT's iat, exp and nbf claims are NumericDate values: seconds since 1970-01-01T00:00:00Z UTC (RFC 7519, section 2). The lifetime is exp − iat. The time left is exp − now. A verifier must reject the token on or after exp and before nbf; iat only records when it was issued.
Size is cookie name + token in bytes. A token is three base64url parts joined by periods, and base64url turns every 3 bytes into 4 characters (unpadded length = ceil(4n/3)). That is why a 256-byte RS256 signature alone takes 342 characters, and a 32-byte HS256 signature takes 43.
Worked example
Click Load example. The token has iat = 1700000000 (2023-11-14T22:13:20Z) and exp = 1700003600 (2023-11-14T23:13:20Z), so the lifetime is 3600 seconds, exactly 1 hour. The token is 143 characters. With a cookie named session (7 bytes) the name plus value is 150 of 4096 bytes, leaving 3946. Because the example expired in 2023, the tool reports it as expired against today's clock; that is the correct result for it.
What this checks
- exp minus iat as a lifetime, plus time left and token age
- exp not after iat or nbf, which makes a token never valid
- Values that look like milliseconds instead of seconds
- Missing exp or iat, which RFC 7519 allows but which removes the built-in limit or the lifetime
- Name plus value in bytes against 4096, and optionally with attribute text added
Sources and limits
Claim rules: RFC 7519, JSON Web Token, sections 2, 4.1.4 (exp), 4.1.5 (nbf) and 4.1.6 (iat). Compact serialization and unpadded base64url: RFC 7515. Cookie size: draft-ietf-httpbis-rfc6265bis (name and value over 4096 octets are ignored) and RFC 6265 section 6.1 (at least 4096 bytes per cookie, counting name, value and attributes). All read 1 October 2026; the cookie draft may change.
This tool does not verify the signature. A readable exp proves nothing about who issued the token. The 4096 figure is a floor that browsers must support, not a guarantee: proxies, servers and total request-header limits can reject a request sooner, and those limits are not defined by the RFCs, so they are not checked here.
Sizing a token, piece by piece
A compact JWT is three base64url strings joined by two periods, so its length is the sum of three parts plus 2. Every 3 bytes become 4 characters, so a part of n bytes takes ceil(4n/3) characters. Here is a small token worked out by hand:
- Header
{"alg":"HS256","typ":"JWT"}is 27 bytes, which is 36 characters. - Payload
{"sub":"user_8841","role":"editor","iat":1700000000,"exp":1700003600}is 69 bytes, which is 92 characters. - An HS256 signature is 32 bytes, which is 43 characters.
- Total: 36 + 92 + 43 + 2 periods = 173 characters. In a cookie named
session(7 bytes) that is 180 of the 4,096 bytes allowed for name plus value, so 3,916 remain.
Switch the signature to RS256 with a 2048-bit key and the signature alone is 342 characters, so the same claims become 36 + 92 + 342 + 2 = 472 characters. With that signature, a 7-byte cookie name leaves room for roughly 2,780 bytes of JSON claims before name plus value reaches 4,096; with HS256 it is roughly 3,000. Each additional 100 bytes of JSON adds about 134 characters. Role and permission arrays are the usual cause of tokens that stop fitting in a cookie.
Choosing and reading an expiry
RFC 7519 makes exp optional and does not say how long a token should live. That is your decision. The lifetime this tool reports is exp minus iat, so a lifetime of 900 is 15 minutes, 3,600 is one hour, 86,400 is one day and 2,592,000 is 30 days. A longer lifetime means a stolen token stays useful for longer, so the choice trades convenience against the damage from a leak. Because a verifier checks exp, nbf and the signature but a JWT cannot be recalled once issued, many systems keep access tokens short and renew them. Whatever you choose, the verifier is the place that enforces it: this calculator only reads what the token claims.
Mistakes the checks catch
- Milliseconds instead of seconds. A 13-digit exp such as 1700003600000 is a JavaScript timestamp. NumericDate counts seconds, so read as seconds it lands tens of thousands of years in the future.
- exp earlier than iat or nbf. The token was never valid.
- Missing exp. Allowed by the RFC, but then nothing in the token limits its life.
- Counting only the token toward the cookie limit. The name counts too, and the attributes (Path, Secure, SameSite) count against RFC 6265's per-cookie minimum.
To read the claims of a token you hold, use the JWT decoder. To check how a cookie header will be read, use the Set-Cookie inspector.
Frequently asked questions
What is the difference between iat and exp in a JWT?
Both are NumericDate values: seconds since 1970-01-01T00:00:00Z UTC. iat (issued at) records when the token was issued; exp (expiration time) is the moment on or after which a verifier must not accept it. The lifetime is simply exp minus iat. Both claims are optional under RFC 7519.
How do I turn exp into a date?
Multiply by 1000 for a JavaScript Date, or read the ISO date this tool prints. The value is in seconds, not milliseconds. A 13-digit number is almost certainly milliseconds by mistake and would land thousands of years in the future.
How big can a JWT be if I store it in a cookie?
A browser following the RFC 6265bis parsing algorithm ignores a cookie whose name plus value is more than 4096 octets. RFC 6265 section 6.1 describes the 4096-byte minimum as covering name, value and attributes together, so leave headroom for attributes like Path, Secure and SameSite.
Why is my JWT so large?
Each of the three parts is base64url encoded, which turns every 3 bytes into 4 characters, so the token is about a third larger than the raw JSON plus signature. An RS256 signature from a 2048-bit key is 256 bytes, which is 342 characters on its own. Every extra claim, role list or permission array adds to the total.
Does this tool check the signature or tell me the token is valid?
No. It reads the payload and does arithmetic. Anyone can write a token with any exp, so a readable exp says nothing about whether the issuer signed it. Signature verification must happen on your server with the right key.
Does the cookie limit count characters or bytes?
Octets, which are bytes. A valid compact JWT is ASCII, so characters and bytes match, but the cookie name is counted too. This tool counts UTF-8 bytes of the token and the name you enter.
How much clock skew should I allow when checking exp?
RFC 7519 says an implementation may allow some small leeway, usually no more than a few minutes, to account for clock skew. It does not set a number. Pick the smallest value your systems can live with and keep it in verifier configuration, not in the token.
Cite this page: TNAADO Tools, "JWT Expiry & Cookie Size Calculator", tools.tnaado.ca/security/jwt-expiry-size-calculator/, sources RFC 7519, RFC 6265 and RFC 6265bis draft, reviewed 1 October 2026.