How accurate are online stopwatches?

Short answer: a well-built one is accurate to well under a tenth of a second over any realistic session — but many are not well built, and the difference is one design decision: whether the clock counts ticks or reads timestamps.

The tick-counting trap

The simplest way to write a stopwatch is a loop that fires every 10 milliseconds and adds 10 to a counter. It looks right in a quick test. The problem is that browser timers are requests, not promises: a busy page delays them, and an inactive tab can have its timers throttled to once per second — or once per minute. Every delayed tick still adds only its nominal 10 milliseconds, so the counter silently falls behind real time. Leave a tick-counting stopwatch in a background tab for an hour and it can read minutes slow, without anything looking broken.

The timestamp method

A timestamp stopwatch never adds anything up. It writes down the instant you pressed start — from performance.now(), a monotonic clock that is not affected by system time changes — and every time the display refreshes it computes elapsed = now − start. Pausing banks the elapsed number and clears the start instant; resuming writes a new one. If a refresh is delayed, the next frame simply shows a slightly larger jump. The reading converges on the truth instead of accumulating error, which is why every timer on this site — the stopwatch, the countdowns, the Pomodoro and the interval timer — is built this way.

The honest limits

Timestamp timing removes the drift problem, not physics. Four limits remain, and any site that hides them is overselling:

• Display refresh. The number on screen updates at most once per animation frame — typically 60 times a second — so the last digit is a snapshot, not a continuous stream.
• Your finger. Human reaction time on start and stop is roughly 150–250 milliseconds, dwarfing every digital error above. For training and cooking this is irrelevant; for race results it is everything.
• Frozen pages. If the device sleeps or the browser is killed, no web page can react at the deadline. A timestamp clock still reads correctly when the device wakes, but it cannot beep while asleep.
• No certification. Browser clocks are excellent engineering tools and poor legal instruments. Anything contractual, medical or competitive-sanctioned needs dedicated timing equipment.

A quick test you can run

Start any online stopwatch, switch to another tab for exactly five minutes by a clock you trust, then switch back. A timestamp stopwatch reads 5:00 give or take your switching time. A tick counter usually reads noticeably less — the gap is the throttling it swallowed. Our stopwatch also survives the nastier version of this test: start it, do something heavy in another tab, and watch it stay true.

Frequently asked questions

Is performance.now() better than Date.now() for timing?

For intervals, yes. Date.now() follows the wall clock and can jump if the system time is corrected; performance.now() is monotonic — it only moves forward, at a steady rate — which is what elapsed-time maths needs.

Why do hundredths on some stopwatches flicker unevenly?

Because display updates are tied to the screen’s refresh cycle and the main thread’s workload. The underlying time is exact; the repainting is best-effort. That is cosmetic, not drift.

Can an online stopwatch time a photo-finish?

No. Even with perfect timestamps, button presses and frame timing are far too coarse. Use it for splits in training, where a tenth of a second either way changes nothing.