Online Stopwatch With Lap Times: How Browser Timing Actually Works

You need to time something — a set of intervals, a build, a rehearsal — and you want the splits recorded, not just the total. An online stopwatch with lap support does that in one tab, no install. This post covers what a lap actually is, why the number on screen is trustworthy even after you switch tabs, and where browser timing stops being good enough.

#TL;DR

• A split is elapsed time from the start; a lap is one segment.
• Store timestamps and subtract — never accumulate per tick.
• Hidden tabs pause repaints, not the clock. The value self-corrects.
• Browser clocks are coarsened to ~100 µs to block timing attacks.
• Your thumb, not the browser, is the dominant source of error.

#How to use an online stopwatch with laps

The interaction model has been stable since mechanical chronographs: one control starts and stops, one records a checkpoint, one clears everything. Everything else is presentation.

#Start, stop, lap, reset — the four controls

Start begins counting up from zero. Lap records the current reading into a list and keeps counting. Stop freezes the display without discarding the list — useful when you want to read a final number before deciding whether to resume. Reset clears both the elapsed time and the lap list.

The one that trips people up is lap-while-stopped. On most tools it does nothing, because a checkpoint on a paused clock is meaningless. If you want a record of "I paused here," stop, note the reading, then resume.

#Keyboard shortcuts that make lap timing usable

Clicking a button with a mouse adds a targeting delay on top of your reaction time. Keyboard control removes it. The convention that most tools follow:

• Space — start / stop
• L or Enter — record a lap
• R or Esc — reset
• F — fullscreen, for timing a room rather than yourself

If you're timing repeated intervals, put your hand on the keyboard before the first rep and leave it there. Consistency in how you press matters more than reaction speed, because a consistent bias cancels out when you compare laps to each other.

#Where your lap data lives

In a client-side tool, nowhere but the page. The iKit Stopwatch & Timer keeps the lap array in memory in your browser; nothing is posted to a server. That's the right trade for privacy and it has one consequence worth stating plainly: closing the tab discards the laps. Copy them out before you close if you need them. Laps are just numbers, so pasting them into a CSV to JSON converter is enough to get them into a spreadsheet or a script.

#What is the difference between lap time and split time

This is the single most common confusion in stopwatch UIs, and it's worth being precise because the two numbers answer different questions.

#Split time: elapsed since the start

A split is cumulative. Per Casio's operation guide for split and lap times, a split time is the time elapsed from the start up to any point along the course of an event. Splits are monotonically increasing — each one is larger than the last, always.

Splits answer: am I on pace? If you're targeting 40 minutes for 10 km, your 5 km split tells you immediately whether that's still on.

#Lap time: elapsed since the previous lap

A lap is the duration of one segment — the gap between two consecutive checkpoints. Lap times move in both directions: a slow third lap is a bigger number than a fast second one.

Laps answer: where did it go wrong? A pipeline that took nine minutes tells you nothing. Nine per-stage laps tell you the test suite ate six of them.

#A worked example with four laps

Four laps of a track, pressing lap at each line:

Same four button presses, two different readings. The splits show a steady climb; the laps show the runner fading through lap three and finding something for the last one. Most stopwatches store the split and derive the lap by subtraction, which is why lap totals always reconcile exactly to the final time — there's no rounding drift between the two views.

If what you actually want is a countdown to a fixed calendar moment rather than a count-up with checkpoints, that's a different tool entirely — a countdown timer anchors to a date instead of a duration.

#Why does my stopwatch lose time in a background tab

It doesn't. The display goes stale; the clock is fine. Understanding the distinction is the difference between a stopwatch you can trust and one you can't.

#requestAnimationFrame stops when the tab is hidden

A stopwatch that shows hundredths needs to repaint often, and the correct scheduler for that is requestAnimationFrame. MDN's requestAnimationFrame() reference notes that callbacks generally match the display refresh rate and are paused in most browsers when the page is in a background tab, to save battery.

So a hidden stopwatch stops repainting. That is correct behaviour — repainting a display nobody is looking at is pure waste.

#The fix: store timestamps, never accumulate

Everything hinges on how elapsed time is derived. The broken pattern adds a fixed amount every tick:

// Wrong: every late frame is lost forever
let elapsed = 0;
setInterval(() => {
  elapsed += 10;
  render(elapsed);
}, 10);

The correct pattern stores an origin and subtracts:

const t0 = performance.now();
let laps = [];

function frame() {
  render(performance.now() - t0);
  requestAnimationFrame(frame);
}

function lap() {
  laps.push(performance.now() - t0);
}
requestAnimationFrame(frame);

Nothing accumulates. A frame that arrives late renders a slightly stale value once and then self-corrects. When the tab comes back after four minutes hidden, the very first frame reads the clock and prints the right number — no catch-up loop, no drift.

Note that lap() reads the clock directly rather than reusing the last rendered value. That matters: the rendered value can be up to one frame old, and on a 60 Hz display that's about 17 ms of error baked into every lap.

#Keeping the screen awake with the Screen Wake Lock API

A stopwatch running on a phone propped against a wall hits a different problem: the screen dims and locks after a minute. The Screen Wake Lock API exists for this, and reached Baseline availability across current browsers in March 2025. A page requests a lock, holds a sentinel object, and releases it when the activity ends:

let sentinel = null;
try {
  sentinel = await navigator.wakeLock.request("screen");
} catch (err) {
  // Denied — low battery or power-save mode
}

Two caveats. The request can be refused for system reasons such as low battery, so it must be treated as best-effort. And the lock is dropped automatically when the document stops being visible, so it has to be reacquired on visibilitychange if you want it back.

#How accurate is an online stopwatch

Accurate enough that you are the limiting factor. Here's where each source of error actually comes from.

#performance.now() is coarsened on purpose

performance.now() returns a monotonic reading: per MDN's performance.now() documentation it is relative to a monotonic clock whose value never decreases and isn't subject to adjustments — no NTP correction, no daylight-saving shift, no user dragging the system clock backwards mid-measurement. That's exactly what you want for a duration.

The resolution is deliberately blunted. To defend against timing attacks and fingerprinting, browsers coarsen the value to 100 microseconds in ordinary pages, and 5 microseconds in cross-origin-isolated ones. Both are three orders of magnitude below anything a human can perceive.

#Your reaction time is the real error bar

Simple visual reaction time for an alert adult sits in the low hundreds of milliseconds. That means the gap between the event and your thumb dwarfs everything the browser contributes by a factor of roughly a thousand.

This is why hand timing is not treated as equivalent to electronic timing in competition. World Athletics maintains separate standards for hand-held and fully automatic times in its Book of Rules, with hand times recorded to a coarser resolution precisely because the human in the loop is the dominant uncertainty.

The practical upshot: report browser stopwatch results to a tenth of a second. The hundredths digit is real, but it's measuring your thumb.

#When a browser stopwatch is the wrong tool

For code, don't hand-time at all. performance.now() around the operation, or console.time() in the devtools console, removes the human entirely and gives you the microsecond-scale answer the clock is actually capable of.

#Online stopwatch vs phone stopwatch vs sports watch

None of these is strictly better. They're optimised for different situations.

#Where the browser wins

• It's already open. No unlocking a phone, no hunting for an app.
• It's big. Fullscreen on a laptop or projector times a whole room.
• Laps are readable. A wide screen shows twenty laps at once; a watch shows three.
• Multiple instances. Several tabs, several independent stopwatches.
• Nothing is uploaded. A client-side stopwatch has no network calls to make.

#Where the phone and the watch win

A phone survives you closing the laptop, and its alarms cut through Do Not Disturb. A sports watch is on your wrist, waterproof, and its lap button is a physical thing you can hit without looking — which is worth more than any amount of precision when you're mid-effort. Neither of those is something a browser tab can offer.

#Getting laps out before you close the tab

Because a client-side tool holds laps in page memory, exporting is deliberate rather than automatic. Copy the list as text, or as comma-separated values if it's headed for a spreadsheet. If you're logging results into a system that stores epoch times rather than durations, the Unix timestamp converter will turn the wall-clock moment of each lap into the integer your database wants.

The privacy point is small but real. A stopwatch reading is not sensitive. What you labelled it — "candidate 2 presentation", "incident response drill" — can be. Every tool in the iKit suite runs entirely in the browser, so labels and laps both stay on your machine.

#References

• Split Times and Lap Times, Module No. 5512 EDIFICE — CASIO — manufacturer definitions of split time and lap time used for the distinction in this article.
• Performance: now() method — MDN — monotonic-clock semantics and the 100 µs / 5 µs resolution coarsening figures.
• Window: requestAnimationFrame() method — MDN — refresh-rate matching and the pausing of callbacks in background tabs.
• Screen Wake Lock API — MDN — Baseline status since March 2025, the sentinel model, and automatic release on visibility change.
• World Athletics Book of Rules — the separate treatment of hand timing and fully automatic timing in competition rules.

#Related on iKit

• Online timer: how to run an accurate countdown in your browser — the countdown half of the same tool, including Chrome's throttling tiers and why setInterval drifts.
• Epoch time units cheat sheet: seconds, millis, micros, nanos — which unit a lap value is in, and how to convert before writing it anywhere else.
• Why your JavaScript timestamp is 1000× bigger than your backend's — the millisecond-vs-second mismatch that turns a 90-second lap into a 25-hour one when it lands in a database.
• Convert a date to a Unix timestamp in Bash, Python, JS and SQL — producing the epoch values you need when logging lap results alongside wall-clock times.