📐Browser timer accuracy: what we measured

By the TimerPlan time desk

✓ Tested & verified Updated: Aug 11, 2026 How this works

Measured in Chrome 151 with a genuinely frozen tab, a countdown computed from an absolute finish time lost 0 milliseconds out of 150 seconds, one built by subtracting a second per tick lost 119 seconds, and one built by subtracting each animation frame lost 147. All three are exact while the tab is in front; the difference only appears when the browser stops running the page, which it does to every background tab.

That is the whole of the argument. A timer is a thing you set and stop looking at, so the only state that matters is the one where the page is not being watched — and it is exactly the state the two common implementations cannot survive.

TimerPlan uses the first method everywhere: one stored finish time, and a display that subtracts. The numbers below are ours, produced by the script in the site’s own repository.

The measurement

Chrome 151, Windows, measured 11 August 2026. Every figure is what each method reported as elapsed, against the system clock outside the browser.

Scenario	Real elapsed	Absolute finish time	Tick counting	Frame counting
Tab in front, 30 s	30 005 ms	30 004 ms	30 000 ms	29 989 ms
Frozen 30 s of 60	60 002 ms	59 014 ms	30 000 ms	2 997 ms
Frozen 120 s of 150	150 002 ms	150 002 ms	31 000 ms	2 986 ms

Read as error, which is the way it matters:

Scenario	Absolute	Tick counting	Frame counting
Tab in front, 30 s	−1 ms	−5 ms	−16 ms
Frozen 30 s of 60	−988 ms	−30 s	−57 s
Frozen 120 s of 150	0 ms	−119 s	−147 s

Three facts are worth pulling out, because they are the ones worth citing:

A frozen tab costs a tick-counting timer exactly the frozen time. Two minutes away, two minutes lost — 119 seconds of 120, which is the freeze plus rounding.
Frame counting is worse than tick counting, not better. Animation frames stop before timers do, so 150 seconds became 3.
An absolute finish time loses nothing. Zero milliseconds over 150 seconds, because there is nothing to lose: the number is a subtraction from a clock that never stopped.

The one-second error in the middle row is the reading, not the timer — the value is sampled on the page’s own one-second interval, so the sample can be a second old. The 150-second run, where the read landed just after a tick, shows the true figure.

Why the other two methods exist at all

Because both are the obvious way to write it. Subtracting a second every second reads correctly, and subtracting the time since the last frame reads even better — it is what an animation would do. Both are also correct on the page you are looking at, which is the state a developer tests in.

They fail in the state nobody tests: the tab in the background, the phone in a pocket, the laptop lid half closed. That is also the only state a timer is really for.

What accuracy does not fix

A countdown that is exact and silent is still useless, and the sound is a separate problem with the same cause. A frozen tab cannot run the code that starts a sound, so an alarm triggered at zero never fires; an alarm scheduled onto the audio clock when the timer starts fires regardless, because the audio hardware is holding the appointment rather than the page. That is why every timer here books its tone at the start and why none of them uses an audio file.

The online timer and everything under timers run on the method in the first column. If you want to see the difference without measuring it, set a five-minute timer here and one on any page that counts frames, switch tabs for two minutes, and come back.

Frequently asked questions

How was the tab frozen?

Through Chrome’s own lifecycle control, the same mechanism the browser applies to background tabs: the page is put into the frozen state, which stops its timers and its animation frames entirely, and then made active again. It is not a simulation of throttling — it is the state itself, driven from outside the page so that the measurement cannot be influenced by the code being measured. Elapsed time is taken from the system clock outside the browser.

Why does the absolute method show a one-second error in the middle test?

Because of when it was read, not what it holds. The value is copied out on the page’s one-second interval, so the sample can be up to a second stale — the underlying number is a subtraction from the system clock and cannot be wrong. The 150-second test, where the reading happened to land after a tick, shows the true figure of zero.

Do these results apply to phones?

More strongly, not less. Mobile browsers suspend background tabs sooner and more aggressively than desktop ones, and locking the screen freezes them immediately. The methods that lose time on a desktop lose more of it on a phone, which is where most kitchen timers are actually set.

Can I run the measurement myself?

Yes — the script lives in the site’s source as meranie-presnosti.mjs and drives a local Chrome through the DevTools protocol. It builds a page containing all three implementations at once so that they experience identical conditions, freezes it for a set period, and compares each reported figure with the system clock. Nothing about it is specific to this site.

Does an accurate countdown mean the alarm sounds on time?

Not on its own, and this is the second half of the problem. A frozen tab cannot execute the line of code that starts a sound, so a timer that waits for zero before making a noise is silent no matter how accurate its arithmetic. The fix is to schedule the tone at a fixed point on the audio clock when the timer starts, which is what this site does; a page using an audio element cannot, because playback needs the page to be running.

How this works

A single page holds all three implementations, so they run under identical conditions in the same tab and no scheduling difference between them can be attributed to the environment. The page is driven by an external script through the Chrome DevTools protocol, which starts the run, freezes the page for a fixed period using Chrome’s page lifecycle control, restores it, and reads all three values at the end. Elapsed time is taken from the system clock in that external script, never from inside the page. Each scenario runs in a fresh tab — the first version of this measurement reused one tab and the previous run’s interval survived, doubling the tick figure, which is the kind of error that produces a confident and wrong table. The figures below are single runs at the stated durations, rounded to the millisecond, on Chrome 151 on Windows.

Sources:

Cite or reference this page

You are welcome to reference the figures on this page with attribution. Every number is generated from the data source at build time — the methodology above explains how.

“Browser timer accuracy: what we measured.” TimerPlan, updated Aug 11, 2026, https://timerplan.com/timer-accuracy/

Three ways to build a countdown

Absolute finish time. Store the clock time it ends and subtract on every redraw. Nothing accumulates, so nothing can be lost.

Subtract a second per tick. A repeating timer takes a second off a remaining total. Loses exactly as much as the browser withheld.

Subtract each frame. An animation-frame loop takes off the time since the last frame. Loses the most, because frames stop first.