A stopwatch and a countdown on a monotonic clock, so neither loses time to a pause, a background tab or the system clock changing. Lap splits that add up, and a countdown that survives a reload.
Initializing in your browser…
Work and break cycles on a monotonic clock, so a session is not ended by the system clock changing, with the running session and today figures kept if you reload.
An upper bound on how strong a password is, from the patterns that actually make one guessable, with the model and its limits stated in full.
Build a cron expression and see its next runs in the zone the job will actually run in, with the day-of-month OR day-of-week rule and the daylight saving rules of crontab(5) applied
You are timing three rounds of a workout and need lap splits without fumbling for your phone.
Actions
Start → Lap (1:58.4) → Lap (2:05.1) → Lap (1:51.7) → Stop
Recorded session
Lap 1 01:58.40 Lap 2 02:05.10 (slowest) Lap 3 01:51.70 (fastest) Total 05:55.20
The stopwatch records each lap as an independent split while keeping a running total, so you see both per-segment pace and elapsed time at once. Elapsed time is computed from wall-clock timestamps captured at start and at each lap, not by incrementing a counter every tick, so the splits stay accurate even if the timer interval fires unevenly.
A stopwatch with lap splits and a countdown with presets, both read from a monotonic clock. Neither loses time to a pause, to a background tab, or to the system clock changing, and a running countdown is picked up again if you reload.
A browser gives a page two clocks and they are not interchangeable. **`Date.now()` is the wall clock**, the machine own idea of the current time, and it jumps: daylight saving moves it an hour twice a year, and the time daemon steps it whenever the machine has drifted. **`performance.now()` is monotonic**, specified never to run backwards and never to jump. The version of this tool that shipped before September 2026 used the wall clock. Driven for 600 ms and then given a one hour clock step, its stopwatch went from 00:00.60 to 01:00:01.10: it had timed the DST transition rather than the run. Both clocks here come from `performance.now()`, and the same measurement moves the reading by zero.
**A paused value has to be read from the clock, not from the last drawn frame.** The shipped stopwatch banked whatever number was last on the screen, and the screen was redrawn every ten milliseconds, so every stop lost up to a tick. Measured with the clicks and the timing done inside the page, so the bound is one millisecond wide: fifteen 200 ms runs really took between 3,013 and 3,014 ms and the stopwatch reported 2,870, losing 9.5 ms a cycle. The version here reads the clock at the moment you press it and lands inside that same one millisecond bound.
**A finished countdown has to still be on the screen.** The shipped timer set its remaining time to zero and its running flag to false, and its whole display, including the "Timer Complete!" message it contains, was rendered behind a condition that both of those made false. Driven for five seconds past a three second countdown and read six times, the message appeared zero times: the panel simply vanished at the instant it was meant to fire, and the page looked as though nothing had been started. Finished is its own state here and it stays on the screen.
**And what no page can promise.** A browser throttles a background tab to about one timer callback a second, and to one a minute after five minutes in the background, so a chime cannot sound at the exact moment if the tab is asleep. What a page CAN do is compute rather than count, so the reading is right the moment it runs again, and say how late it noticed. Both are done here: starved of every timer callback for five seconds across the end of a four second countdown, this timer reports finished as soon as it runs again and prints how long ago it really ended. A running countdown is also written to this browser, so a reload or a crash picks it up where it was rather than losing it.
The lap list accounts for the whole run. The shipped one listed only the closed laps, so the time since the last lap was on the big display and nowhere in the list, and it printed each split without the sub-second digits the display claims, which made every lap under a second read "+00:00". Here the segment still running is listed too, marked, and the page states that the splits add up to the time on the clock, which the module checks rather than asserts.
Three laps taken at 0.4, 0.8 and 1.2 seconds, read at 1.7 seconds. The list shows four rows: three closed splits and the 0.5 second one still going, and their sum is the 1.7 seconds on the display.
The reading is computed from the clock rather than counted up, so a throttled tab loses frames and not time.
Every split is shown to the centisecond, including the one still running, and they add up to the total.
It is written to this browser and picked up where it was.
The time keeps being counted, because it is computed from a clock rather than accumulated a tick at a time. What stops is the drawing: a browser throttles a background tab to about one timer a second, and to one a minute after five minutes. So the display freezes and is correct again the instant you return, and the chime waits until the tab runs. When that happens the page tells you how long ago the timer really finished.
Almost certainly because it was reading the wall clock and the machine clock moved, which happens at a daylight saving change and whenever the time daemon corrects a drift. This one reads a monotonic clock, which is specified never to jump.
No. A running or paused countdown is written to this browser and picked up when you come back, with the elapsed time taken off. A stopwatch is not saved: it resets on a reload.
No. Everything here runs in the page, so the page has to exist. A background tab is enough; a closed one is not.
This runs as client-side JavaScript. Keys, tokens, payloads, and other inputs never leave your device.