A double click test is a browser-based measurement of the gap between two click events on the same target, reported in milliseconds and rounded to one decimal place. It does not read your mouse hardware, your operating system settings, or anything outside the page; it subtracts the timestamp of the first click from the timestamp of the second click as the browser hands them to the page, and only keeps the result if the second click arrives within a defined pairing window. The pairing window is a product rule, not a standard. The tool exposes three numbers from your session: the most recent interval, the fastest interval you produced, and the arithmetic mean of everything retained, plus a count of completed pairs. Because the measurement is taken in the browser, it includes every delay that lives between your finger and the event listener: hand movement, the pointing device's firmware, wireless or wired transport, operating system scheduling, browser event delivery, and whatever load the device is under at that moment. Understanding this scope is what separates a useful comparison from a misleading one.
What a Double Click Test Measures in the Browser
A double click test reports a single value: the elapsed time, in milliseconds, between the browser's recorded timestamp on click one and the browser's recorded timestamp on click two, when both clicks land on the same target within a defined window. Each completed pair becomes one sample in a small session history. The page rounds the sample to one decimal place before it appears in the list, before it is used in statistics, and before it is averaged. Because the rounding happens before averaging, the displayed mean can differ very slightly from a recomputation you do by hand on the raw timestamps; this is a presentation choice, not a measurement error.
The tool is narrow on purpose. It does not know your mouse model, your USB polling rate, your display refresh rate, your wireless environment, your accessibility configuration, or your operating system's double-click speed. It knows only what the browser tells it through click events. That narrow contract is also the reason two different devices on the same desk can produce two different intervals without either being wrong, and why a fast pair on this page does not automatically mean another application will recognise the same action as a double click.
Why the One-Second Window Matters
The 1,000-millisecond pairing window is the tool's most important rule, and it is the reason a slow click does not pollute your average. Once you click the target for the first time, the page starts waiting for a second click. If the second click arrives within one second, the pair is recorded as a sample and the wait resets. If the second click arrives later than one second, the page does not record it as a pair. Instead, it tells you that the previous pair timed out, treats that late click as the start of a new pair, and begins waiting again.
This rule keeps two things honest at once. First, it makes every displayed interval easy to reproduce: if you pause for thought between clicks, your pause shows up as a timeout, not as a misleading slow sample. Second, it prevents a single long pause from dragging your arithmetic mean upward and making a healthy hand look sluggish. The 1,000 ms figure is a product decision for this tool; it is not a recommendation about how fast a "real" double click should be. Operating systems, applications, and games each define their own thresholds, and they do not consult this page.
How to Run the Double Click Test
The whole test lives on one page. Follow the steps below to build a small, reproducible sample and read the result.
- Open the Double Click Test page and place the pointer over the large test area so the cursor is steady.
- Click once. The page registers this click as the first timestamp of a new pair and waits for a second click within one second.
- Click the same area a second time within 1,000 ms. The interval between the two browser click timestamps is recorded as a completed pair, rounded to one decimal place, and added to the session.
- Repeat step 3 several times under the same conditions to build a small sample. Try to keep your hand position, pointing device, and surroundings unchanged between pairs.
- Read the latest interval, the best (minimum) interval, the arithmetic average, and the completed pair count shown above or beside the target.
- Click Reset to clear all retained samples and start a new session, or refresh the page if you want a clean slate.
Reading Latest, Best, and Average
Three numbers are exposed from the same set of retained samples, and they answer three different questions.
Latest is the interval of the pair you most recently completed. It is useful for spotting a sudden change, such as a hand cramp, a shift in seating, or a wireless hiccup.
Best is the fastest pair you have produced in this session. It represents your lower bound under the current conditions and is the easiest number to defend when comparing two devices, because it strips out fatigue and pauses.
Average is the arithmetic mean of every retained sample, rounded to one decimal place. It is the most stable single number for describing a session, but it loses outliers only by averaging rather than by rejecting them. If you produced one accidental 900 ms pair in a session of twenty fast pairs, your average will rise even though your hand did not slow down.
Up to fifty pairs are kept. Once the session reaches that bound, the next completed pair replaces the oldest, so a long session still summarises recent behaviour rather than your very first attempts. The pairing rule is deliberately visible and simple, and pairs do not overlap, so the second click of one result is never reused as the first click of the next result.
What the Tool Does Not Diagnose
A double click test result is a comparison number, not a verdict. The page does not label any interval fast, normal, slow, passing, or failing, and it should not be used as a hardware test. The interval you see includes human movement, pointing-device firmware, wireless or wired transport, operating-system scheduling, browser event delivery, display timing, and current device load, and the page cannot separate these contributors.
It also cannot isolate hardware latency. If you are investigating unwanted duplicate clicks in another application, the comparison you need is between this page's intervals and the affected application's own log, taken with the same pointing device and the same hand position. A browser tool cannot tell you whether a switch is failing, whether the USB polling rate has dropped, or whether the wireless receiver needs to be moved. If those questions matter, the responsible next step is to test another port or device only when it is safe to do so, and to use the operating system's built-in mouse settings for any threshold change.
The target is keyboard-focusable for navigation, but the measurement itself responds to click events. Touchscreens and assistive technologies can synthesise click events, so a result on a trackpad, a touch screen, or a switch interface represents that input method, not a desktop mouse. High system load, remote desktop software, automation, or background activity can also change event delivery and should be noted when comparing sessions.
Comparing Input Methods and Conditions
The same hand can produce noticeably different intervals depending on what is generating the click events. The table below describes the typical direction of those differences qualitatively; for exact figures on your device, the page itself is the source of truth.
| Input or condition | Typical effect on the interval | What the page can and cannot say |
|---|---|---|
| Wired mouse, seated, idle system | Lowest and most stable intervals | Useful for a clean baseline comparison |
| Wireless mouse, normal load | Slightly higher and more variable intervals | Transport and receiver noise are included but not separated |
| Trackpad tap-to-click | Often higher than a click on the target | Firmware debounce and gesture handling are included |
| Touchscreen tap | Variable, depends on contact area and release point | A tap is a click event, but the page does not label it as touch |
| Automation or repeated synthetic input | Very low intervals and a long sample history | Helps confirm the page is responding, not the user's hand |
| High system load or remote desktop | Higher and more variable intervals | Load is included; the page does not report it separately |
When a Double Click Test Is Worth Running
The most useful moment to run a double click test is when you want a like-for-like number to compare two situations, not a single absolute score. If you have switched from a wired to a wireless mouse, swapping the device and then producing pairs under the same conditions will tell you whether the transport is adding visible delay in your environment. If you suspect a switch is double-clicking on its own, comparing the intervals this page records against the behaviour in the affected application can show whether a stray second click is happening too quickly for a human hand to produce.
It is also useful when you are documenting a complaint or a support case. A short list of recent intervals, kept under known conditions, is easier to share than a vague description of "weird clicks." For a meaningful comparison, keep your hand position, your device, and your surroundings as constant as possible between sessions, note anything obvious that changed, and reset the page before each new comparison so that the arithmetic average is built only from the samples that belong to that condition. Browser zoom does not change the timestamp subtraction, so adjusting the page size will not bias the result.
For deeper context on how the browser decides what counts as a double click in the first place, see how double clicking works in a browser. All samples stay in the current page, are not uploaded, are not associated with an account, are not saved after refresh, and are not used to identify a device, which makes the test safe to repeat in private.