⏱️ DNS TTL Converter

Enter a DNS TTL value in seconds to see it as a human-readable duration, or enter days/hours/ minutes to get the seconds value to put in a DNS record.

How the seconds are broken up

The conversion is plain integer division, done in your browser - no lookup is made:

days    = floor(s / 86400)
hours   = floor((s % 86400) / 3600)
minutes = floor((s % 3600) / 60)
seconds = s % 60

Zero parts are dropped, so 3600 reads 1h, 900 reads 15m and 90061 reads 1d 1h 1m 1s. The rows underneath give the same figure as minutes, hours and days: 3600 seconds is 60.00 minutes, 1.000 hours, 0.0417 days. To go the other way, multiply - 4 hours is 4 × 3600 = 14400, and a week is 604800.

What the TTL actually controls

The TTL is not how long your provider waits. It is the number of seconds a resolver that has already fetched the record may keep answering from its own copy before asking again. Set 86400 and a resolver that cached your old address a minute ago will serve it for another 23 hours 59 minutes, whatever you change at the registrar. That is the whole of "propagation": caches timing out, one at a time.

Lower the TTL to 300 at least one full old-TTL period before a migration. Cutting it on the day is too late - the caches that matter already hold the record with the long TTL attached.

Frequently asked questions

What is a good TTL for a DNS record?

3600 seconds for records you rarely touch, 300 while you are actively moving something, and 86400 or more for NS records that never change. Below 60 the query load rises sharply for very little gain.

How many seconds is a 24 hour TTL?

86400. An hour is 3600, a day 86400, a week 604800 and 30 days 2592000. Those four cover nearly every TTL you will be asked to enter.

Does lowering the TTL make my change take effect faster?

Only for changes made after the lower TTL has itself propagated. Resolvers honour the TTL they were handed with the cached copy, so the old value survives for the old TTL no matter what you set afterwards.