DNS TTL Converter (Seconds to Human-Readable)

Convert a DNS TTL in seconds to a readable duration like 1d 2h, with a plain-English note on its caching impact. Runs in your browser.

Human-readable
1h

Cache impact: Short — changes propagate within an hour. Good default while actively making changes.

About this tool

A DNS record's TTL (time to live) is the number of seconds that resolvers and clients are allowed to cache it before checking again. DNS zone files express it as a raw integer — 3600, 86400, 300 — which is easy to misread, so this tool converts any TTL into a clear duration like '1d' or '1h 30m' and explains what that value means in practice. The trade-off behind the number is the whole point: a short TTL means changes propagate quickly but every client re-queries often, adding load and a touch of latency; a long TTL means excellent caching and minimal queries but a record change can take that long to reach everyone. The common pattern is to lower the TTL a day or two before a planned migration, make the change, confirm it, then raise it again. The conversion is exact and runs entirely in your browser.

How to use it

  • Enter the TTL value in seconds, or pick a common preset.
  • Read the human-readable duration.
  • Check the cache-impact note to see how it affects propagation and query load.
  • Lower the TTL ahead of a planned DNS change, then raise it afterward.

Frequently asked questions

What does DNS TTL actually control?
How long a resolver or client may cache the record before it must ask the authoritative server again. A TTL of 3600 means cached for up to one hour. It does not change the record's value — only how long stale copies may linger.
What TTL should I use?
For stable records, a longer TTL (a few hours to a day) reduces query load and improves resilience. For records you may change soon, drop to 300 seconds (5 minutes) so updates propagate fast. Many providers default to 3600 (1 hour) as a balance.
Why do my DNS changes take so long to appear?
Because resolvers cache the old record for up to its previous TTL. If the record had a TTL of 86400 when it was cached, some resolvers may serve the old value for nearly a day even after you change it. Lowering the TTL in advance avoids this.
Does a lower TTL hurt performance?
Slightly. Shorter TTLs cause more frequent lookups, which adds a small amount of latency on cache misses and more load on the authoritative servers. For most sites the effect is negligible; for very high-traffic domains it is worth tuning.
What is a sensible TTL before a migration?
Lower it to 300 seconds (5 minutes) at least one full old-TTL period before the change, so caches expire and pick up the short value. After the migration is verified, raise it back to your normal TTL.
Is anything uploaded?
No. The conversion is pure arithmetic in your browser with no network request.

Related tools