Second-accurate live countdown to any date you pick. Share the link, go fullscreen.
The timer ticks live every second and shows days, hours, minutes and seconds in large numerals. The browser tab title also reflects the remaining time — perfect for keeping it in the background. The fullscreen button turns the timer into a kiosk display. Settings and target date are stored in localStorage and shared via the URL — every recipient sees the exact same countdown.
Click Copy share link — the URL embeds title, date and time as parameters. Anyone opening the link sees the same countdown. Perfect for invitations, save-the-date emails, or Slack pings before a release.
A digital countdown continuously subtracts the current system time from the target moment. In the browser this works through Date.now(), which returns the number of milliseconds since the Unix epoch 1970-01-01 00:00:00 UTC — the same reference point POSIX time_t uses. The timer on this page recomputes the difference every second instead of incrementing a counter. That matters because setInterval(fn, 1000) is not guaranteed to fire at exactly one-second intervals: when a user switches tabs, modern browsers throttle timers to roughly once per second, and even more aggressively for background tabs. As long as the display is derived from the absolute delta, that does not matter — even after a ten-minute idle period the next tick shows the correct value again.
Things get trickier with time zones and daylight saving time. The browser's date input returns only the calendar date and the time input only the clock time — both are interpreted in the local IANA zone (for example Europe/Berlin). If someone in New York opens your share link with target 2026-12-31 23:00, they see the same wall-clock event, but the UTC representation is six hours later. The countdown itself is correct for both, because internally we work in milliseconds since epoch. At DST transitions defined by EU directive 2000/84/EC (last Sunday in March / October), be aware that one hour exists twice or not at all. Targeting the missing hour on the last Sunday of March yields the next valid timestamp in practice.
Accuracy has physical limits. Leap seconds, inserted via IERS Bulletin C, are typically smoothed by the operating system as a clock jump — the JavaScript timer does not notice and simply jumps along. For regular use cases (birthday, deadline, project kickoff) that does not matter. For a countdown that must match an NTP-accurate rocket launch, you should additionally sync with a server clock. For everything else the system clock is fine — modern devices are accurate to within a few hundred milliseconds of UTC.
Remaining time is simply delta = target_ms - now_ms. From the absolute delta the fields fall out by integer division: days = floor(|delta| / 86,400,000), hours = floor(|delta| / 3,600,000) mod 24, minutes = floor(|delta| / 60,000) mod 60, seconds = floor(|delta| / 1000) mod 60. A day is 86,400 seconds, an hour 3,600, a minute 60. Conversion into days is exact as long as no leap day or DST jump sits between now and the target — and even then the millisecond delta stays correct; only the human perception of "one day later" may slip by one hour. In ISO 8601 duration notation, 1 day 2 hours 3 minutes is written P1DT2H3M.
A handful of real numbers to anchor the orders of magnitude:
1893456000 equals 2030-01-01 00:00:00 UTC — a popular long-term countdown anchor.Worth knowing: a 32-bit signed time_t can only count up to 2038-01-19 03:14:07 UTC — the famous Y2038 problem. Modern systems use 64-bit timestamps, and JavaScript internally uses double-precision floats with a range of roughly 9 quadrillion milliseconds; in the browser this is a non-issue. For very large deltas (> 285,000 years) second-level precision degrades. DST transitions under EU directive 2000/84/EC and regional exceptions (e.g. Morocco, Iran, US states without DST) mean that a wall-clock day is not always 24 hours long — a countdown to "tomorrow 09:00" on a DST weekend can read 23 or 25 hours. Leap seconds (most recently 2016-12-31) also nudge sub-second comparisons. And finally: ISO calendar weeks (ISO 8601, week 1 contains the first Thursday of the year) differ from US calendar weeks (week 1 = week containing January 1) — relevant for "countdown to week 26" scenarios.
Europe/Berlin). If someone in another time zone opens your share link, they see the same wall-clock target — for example "31 Dec 23:00" — but offset to their local clock.