How Browsers Keep a Countdown Accurate in a Background Tab
A countdown that jumps or suddenly stalls the second you switch tabs looks like the tool broke, and the instinct is to reload it and hope the problem doesn't come back. It isn't broken. Switch away from a countdown tab and back, and the numbers sometimes leap instead of ticking smoothly. That's not a bug in the page. It's the browser deliberately slowing things down behind your back.
Timers get throttled the moment a tab loses focus
JavaScript's setInterval and setTimeout were never a hard promise of exact timing, and modern browsers lean on that slack deliberately: once a tab is backgrounded, browsers clamp how often its timers are allowed to fire, specifically to save battery and CPU on inactive pages. Chrome, for example, limits background-tab timers to firing at most about once per second, and applies even more aggressive throttling the longer a tab stays in the background. A documented, intentional part of how the browser schedules work.
This isn't a quirk of one misbehaving site. Chrome, Firefox, and Safari all apply some version of the same clamp to every backgrounded tab, so a countdown that seems to stall while you're reading email in another window isn't a sign it lost its place. The browser is trading redraw frequency for battery life, and the underlying count stays accurate the whole time, whether or not the screen is allowed to update it.
Why a naive countdown drifts instead of just pausing
Whether a stalled countdown catches up cleanly or just sits wrong until you refresh comes down to how it was built, not to anything you did. A countdown built by simply decrementing a counter on every timer tick inherits that throttling directly. If the timer fires less often than expected, the display falls behind real elapsed time, and that error accumulates the longer the tab stays backgrounded. The visible symptom is exactly the jump people notice: the countdown looks like it "catches up" all at once when the tab regains focus, because the underlying counter was quietly falling behind the whole time.
The fix is to stop trusting the tick count entirely
A countdown built correctly doesn't increment anything on each tick at all. It recomputes the remaining time from scratch using the actual system clock (Date.now()) against a fixed target timestamp, every time it updates. Built that way, a throttled or delayed tick doesn't cause drift, because the next tick, whenever it happens to fire, recalculates the true remaining time directly rather than compounding an error from the tick before it.
What this means for the countdown you're using
Browsers provide the Page Visibility API (document.hidden, and the visibilitychange event) precisely so scripts can detect when a tab has been backgrounded and react. A countdown can use it to immediately recompute and redraw the instant the tab becomes visible again, rather than waiting for the next throttled timer tick to catch up on its own.
If the goal is just trusting the number on screen, a well-built countdown is already self-correcting: whatever it shows the moment you switch back is the true remaining time, not a value still catching up. If the goal is building or embedding your own timer, recompute from a fixed target timestamp on every tick instead of counting ticks, and listen for visibilitychange, and background throttling stops being able to introduce drift at all.
Set a live, self-correcting countdown to any date with the countdown timer.