Why a stopwatch shouldn't be built on the system clock
The obvious way to build a stopwatch is checking the system clock (Date.now()) when you start and again when you stop, then subtracting. This works most of the time — but the system clock is exactly that: a clock, subject to adjustment. Network time sync, daylight saving transitions, and manual clock changes can all shift Date.now()'s value mid-measurement, which would make a stopwatch built on it briefly report an incorrect or even negative elapsed time if the clock happened to jump backward during a timing session.
This tool uses performance.now() instead, a timer specifically designed for measuring elapsed durations rather than telling you what time it is. It counts monotonically — meaning it only ever increases, immune to system clock adjustments — and offers microsecond-level resolution, far finer than the centisecond precision actually displayed.
performance.now() vs. Date.now() for timing
| Property | performance.now() | Date.now() |
|---|---|---|
| Purpose | Measuring elapsed duration | Reporting current wall-clock time |
| Affected by clock adjustments | No — monotonic | Yes — can jump forward or backward |
| Resolution | Microsecond-level | Millisecond-level |
| Right tool for a stopwatch | Yes | No |
Using the stopwatch
Click Start to begin timing — the display shows mm:ss.cs, with cs representing centiseconds (hundredths of a second).
Click Lap while running to record a split; each lap shows both its split time and the cumulative total.
Click Pause to halt the timer, then Resume to continue without losing any elapsed time.
Click Reset to clear the timer and all recorded laps. Fastest and slowest laps are tagged automatically once you have at least two.
Split time vs. total time — two different questions about the same lap
Every recorded lap shows two numbers because they answer genuinely different questions: split is the time elapsed since your previous lap — how long that specific segment took on its own — while total is the cumulative elapsed time since you first hit Start. For a runner tracking mile splits, split time tells you how fast that specific mile was, while total time tells you your overall race time at that point. Confusing the two is a common source of misread lap data: a fast overall pace (low total-time growth) doesn't necessarily mean every individual split was fast, and vice versa.
Why laps can only be recorded while running
How fastest and slowest laps get identified
Once at least two laps are recorded, the tool compares each lap's split time — not its total time — and tags the shortest split as Fastest and the longest as Slowest. This comparison is specifically about split duration because that's what's actually comparable across laps of a repeated activity: comparing total time across laps would be meaningless, since total time is cumulative and necessarily grows with every lap regardless of how fast any individual segment was.
Why the timer stays accurate even if you switch browser tabs
Because performance.now() measures actual elapsed wall-clock time rather than counting discrete animation frames, switching to another tab and back doesn't cause the stopwatch to lose or misreport time — when you return, it reads the current performance.now() value and calculates the correct elapsed duration, catching the displayed number up instantly to where it should be. The visual animation of the running display may pause while the tab is hidden, since browsers throttle background tab rendering to save resources, but that's purely cosmetic; the underlying timing calculation stays accurate throughout.
Common mistakes
Trying to record a lap immediately after pausing, without resuming first — the stopwatch needs to be actively running to capture a lap.
Reading total time when you meant to check how fast a specific segment was — split time is the number that answers that question.
Assuming background tab throttling means lost accuracy — the display animation may pause visually, but the actual elapsed time calculation remains correct.
Comparing total times across laps expecting a meaningful 'fastest lap' signal — that comparison is done on split times specifically, for good reason.
Real use cases
Timing interval training with individual lap splits for each repetition.
Tracking cumulative and per-segment time during a multi-stage task or race.
Precisely timing a task where centisecond accuracy actually matters, like a speedrun or timed test.
Running a stopwatch in a background browser tab while working on something else, trusting the elapsed time stays correct.
Frequently asked questions
Q: How accurate is this stopwatch?
A: It uses the browser's high-resolution performance.now() timer, which provides microsecond-level resolution. The display is rounded to centiseconds (1/100 second).
Q: What's the difference between split and total time?
A: Split is the time elapsed since your previous lap. Total is the elapsed time since you started the stopwatch.
Q: Can I record laps while paused?
A: No — the stopwatch must be running to record a lap. Resume first, then capture your lap.
Q: How are fastest and slowest laps identified?
A: After you record at least two laps, the tool highlights the one with the shortest split as Fastest and the longest as Slowest.
Q: Does it keep running if I switch tabs?
A: Yes — performance.now() measures real elapsed time, so the display catches up correctly when you return. The animation may pause while hidden, but the time stays accurate.
Q: Why does the display only show centiseconds when the underlying timer is far more precise?
A: Centisecond precision (1/100 second) is already finer than human reaction time and more than sufficient for virtually any manual timing task, so displaying the full microsecond-level resolution would add visual noise without adding practical usefulness.
Start timing now
Try the Stopwatch. Need to count down instead of up? Use the Countdown Timer or Pomodoro Timer. Working with timestamps or timezones instead? Check the Unix Timestamp Converter or World Clock.
