Hours to Seconds Converter
Convert hours to seconds — for timeouts, encoding settings and cache lifetimes.
Updated
seconds
3,600s
1 h = 3,600 s
In short
How many seconds are in 24 hours?
86,400 seconds. An hour is exactly 3,600 seconds, so multiply by 3,600: one hour is 3,600, a day is 86,400 and a week is 604,800. Configuration fields almost always want a plain non-negative integer of seconds, with no unit and no decimal point.
If a field rejects your value, check its ceiling before checking your arithmetic. Several protocols cap well below the unsigned 32-bit limit.
hours to seconds — quick reference
| hours (h) | seconds (s) |
|---|---|
| 0.5 h | 1,800 s |
| 1 h | 3,600 s |
| 2 h | 7,200 s |
| 4 h | 14,400 s |
| 8 h | 28,800 s |
| 12 h | 43,200 s |
| 24 h | 86,400 s |
| 48 h | 172,800 s |
The formula, worked line by line
One multiplication by an exact constant. The hour is sixty minutes and the minute sixty seconds, both by definition, so 3,600 carries no uncertainty at all. Every complication on this page comes from the field you are pasting into, never from the arithmetic itself.
“The TTL field is a 32-bit signed value, and its maximum is 2,147,483,647 — top bit set means the value should be treated as zero.”
That clarification exists because implementations disagreed. A field described as 32 bits invited some to use the full unsigned range, which produced records that other resolvers read as expired. The fix was to pin the interpretation rather than the width, and it is a good reminder to check a ceiling rather than infer it.
seconds = hours x 3,600
1 x 3,600 = 3,600 seconds
24 x 3,600 = 86,400 seconds in a day
168 x 3,600 = 604,800 seconds in a week
8,760 x 3,600 = 31,536,000 seconds in a 365-day year- Hours wanted
- 36
- Times 3,600
- 129,600 seconds
- Written as a header
- max-age=129600
- What not to write
- max-age=36h, or 129600.0
- The value to paste
- 129600
No unit, no decimal point, no thousands separator. The separators used in the tables on this page are for reading; a configuration field wants the bare digits.
The two thirty-two bit ceilings
They differ by a factor of two and by a great deal of trouble. The signed maximum of 2,147,483,647 seconds is roughly 68 years, and is where a four-byte signed epoch counter overflows on 19 January 2038. The unsigned maximum of 4,294,967,295 is roughly 136 years.
Durations against instants
A field holding seconds is one of two things, and the distinction is invisible in the value. A duration counts forward from now; an instant counts forward from the start of 1970. Putting 3,600 in an instant field does not mean an hour from now, it means one o'clock on the first of January 1970.
- Cache-Control max-age
- duration
- Cookie Max-Age
- duration
- DNS TTL
- duration
- JWT exp and iat
- instant, seconds since 1970
- Cookie Expires
- instant, as an HTTP date
The token claims are the ones people get wrong, because they hold the same kind of number as the cache headers and mean something completely different.
How to use the hours to seconds converter
Multiply by 3,600. An hour is sixty minutes of sixty seconds, so the constant is exact and the arithmetic is one step. What makes this worth a page is that the answer is nearly always going into a machine, and machines have opinions about the format and the range that the arithmetic does not warn you about.
The pattern is consistent across protocols: a duration in seconds is a non-negative integer, written without a unit suffix. HTTP cache lifetimes, cookie expiry, DNS record lifetimes and most application timeouts all follow it. Writing 1.5 where the field wants 5400, or writing "1h" where it wants a number, fails in ways the error message rarely explains.
3,600
One hour
60 x 60
86,400
One day
the standard long cache
604,800
One week
the usual cookie ceiling in practice
Three numbers cover most of the work. A day at 86,400 and a week at 604,800 are the two you will paste most often, and 31,536,000 is the conventional "one year" for a cache header — note that it uses a 365-day year rather than the calendar mean, because a cache does not care about leap years.
The one field that looks like this and is not is a JSON Web Token expiry. The exp claim is not a lifetime in seconds; it is an absolute instant, counted in seconds from the start of 1970. Setting it to 3600 does not give a token an hour of life, it expires the token in January 1970.
- 15 minutes
- 900 s — a typical access token
- 1 hour
- 3,600 s
- 8 hours
- 28,800 s — a working day
- 24 hours
- 86,400 s
- 7 days
- 604,800 s
- 365 days
- 31,536,000 s — the conventional cache year
The last row deliberately uses 365 days rather than the Gregorian mean of 365.2425, because that is the figure the convention actually uses.
Turn an epoch value into a readable date
If the number you are holding is an absolute timestamp rather than a duration, that page converts it both ways and shows what it means in local time.
Open the timestamp converter →Hours converted to seconds, with the setting each figure usually appears in. Every value is exact, since an hour is exactly 3,600 seconds.
| Hours | Seconds | Where it turns up |
|---|---|---|
| 0.25 h | 900 s | short-lived access token |
| 0.5 h | 1,800 s | session idle timeout |
| 1 h | 3,600 s | a standard cache lifetime |
| 1.5 h | 5,400 s | |
| 2 h | 7,200 s | |
| 3 h | 10,800 s | |
| 4 h | 14,400 s | |
| 6 h | 21,600 s | |
| 8 h | 28,800 s | a working day |
| 12 h | 43,200 s | |
| 24 h | 86,400 s | one day |
| 48 h | 172,800 s | |
| 168 h | 604,800 s | one week |
What the protocols actually accept
The rules differ enough to matter. HTTP defines a cache lifetime as a non-negative decimal integer of seconds with no fractional part and no stated upper bound, and requires an overflowing value to be clamped to a large positive number rather than wrapping into a negative one. Cookies use a positive integer count of seconds until expiry, bounded in practice by what dates the browser can represent.
- HTTP Cache-Control max-age
- non-negative integer seconds, no fraction
- Cookie Max-Age
- positive integer seconds until expiry
- DNS record TTL
- integer seconds, 0 to 2,147,483,647
- CoAP Max-Age
- integer seconds, 0 to 4,294,967,295
- JWT exp
- not a duration — an absolute epoch instant
Only one row here is genuinely unsigned 32-bit. The DNS cap is the signed limit despite the field being 32 bits wide.
Two thirty-two bit ceilings recur and they are not interchangeable. 2,147,483,647 is the signed maximum and is also the moment a four-byte signed epoch counter runs out, on 19 January 2038. 4,294,967,295 is the unsigned maximum. Assuming a field is unsigned when it is signed produces a value that is silently treated as invalid or negative.
Choosing a lifetime rather than converting one
The conversion is the easy half. The harder question is what number belongs in the field, and the honest answer is that it depends on how expensive a stale value is against how expensive a fresh fetch is. A long cache is cheap until the day you need to change something quickly.
Do
- Paste a whole number of seconds with no unit suffix
- Set short lifetimes on anything you may need to change urgently
- Use a long lifetime for content addressed by a fingerprinted filename
- Check the field ceiling before assuming a large value was accepted
Don't
- Write a decimal such as 1.5 into a field that wants an integer
- Put a relative duration into a JWT expiry claim
- Assume every 32-bit seconds field accepts the unsigned maximum
- Set a year-long lifetime on a resource whose URL never changes
The practical convention that has emerged is to make the lifetime a function of the URL rather than the content. A fingerprinted asset can hold a year safely because a change produces a new URL; anything served from a stable path should be measured in minutes or hours, because the cache is the only thing standing between an edit and the reader.
Every hours value, worked out
106 common hours figures each get their own page, with the answer, the arithmetic, what rounding costs, and the nearest real-world reference point on the scale.
1 to 9 h
10 to 99 h
Questions people ask
Sources
Where the constants and formulas on this page come from. Each line names the figure it backs.
A cache lifetime is a non-negative decimal integer of seconds, and an overflowing value must be clamped rather than wrapped.
RFC 9111 — HTTP Caching — Internet Engineering Task Force
The DNS TTL is a 32-bit field whose top bit must be zero, giving a maximum of 2,147,483,647 seconds.
RFC 2181 — Clarifications to the DNS Specification, section 8 — Internet Engineering Task Force
Cookie Max-Age is a positive integer count of seconds until the cookie expires.
RFC 6265 — HTTP State Management Mechanism — Internet Engineering Task Force
The JWT exp claim is a NumericDate, an absolute count of seconds from 1970, and not a duration.
RFC 7519 — JSON Web Token, section 4.1.4 — Internet Engineering Task Force
Related guides
Putting JSON in a URL: Validate, Minify, Percent-Encode, or Base64url?
A decision guide for flattening, encoding, checking, and safely transporting JSON in a query string.
August 11, 2026 · 9 min read
How Many Grams in a Cup? Every Ingredient, One Chart
One formula, fourteen densities. Why flour is 120 g, honey is 340 g, and the ingredient — not the cup — decides the number.
August 10, 2026 · 14 min read
How Are Loan Payments Calculated? Amortization, Explained
One level payment, front-loaded interest — the formula worked by hand, the two levers you control, and why the smaller payment is often the costlier loan.
July 23, 2026 · 13 min read