A mouse scroll test is a browser-based diagnostic that records the wheel events a page actually receives while your pointer sits inside a visible test zone, then classifies each event as up, down, left, right, or none based on a disclosed dominant-axis comparison. Unlike a click counter or a polling-rate test, the scroll test does not score speed or grade hardware; it simply reports what the browser delivered to that target in the current tab, including total event count, per-direction buckets, the latest horizontal and vertical delta pair, and signed cumulative X and Y totals. The direction rule is transparent: when both deltas are zero the event is labeled none, otherwise the absolute values of deltaX and deltaY are compared, the larger axis wins, and a tie is given to the vertical axis. Raw deltas are browser event data, not calibrated physical distance, so the same physical wheel notch can produce very different numbers across operating systems, mouse drivers, and trackpads. Reset clears every counter and total without leaving history behind.
What a Mouse Scroll Test Actually Measures
A mouse scroll test isolates one thing: the stream of WheelEvent records a browser fires at a page when you move a wheel or trackpad over a designated target. It does not score how fast you scroll, does not benchmark your hardware, and does not assign a calibrated distance to each movement. Instead, it surfaces four small pieces of evidence that are easy to overlook when you only watch a page slide by. The first is the total number of wheel events in the current session, incremented once for every accepted event. The second is the count inside each of five directional buckets: up, down, left, right, and none. The third is the most recent horizontal and vertical delta pair, written straight from the browser event into the display. The fourth is the signed cumulative X and Y totals, which keep adding the latest deltas to whatever is already on screen.
The point of exposing those values is comparison. When you scroll upward inside the test zone and see an "up" event appear, you have a one-line confirmation that the browser is delivering vertical wheel input the way you expect. When a tilt-wheel mouse scrolls left and you see a "left" bucket tick upward, you know the browser is forwarding that horizontal axis at all. When a trackpad gesture you thought was diagonal lands in only one bucket, you are seeing the deliberate behavior of the direction rule, not a missing axis.
How to Run the Test in Your Browser
The Mouse Scroll Test keeps the procedure to three short steps so the only variable in the session is your own input.
- Place the pointer over the dashed test area and move the wheel or trackpad vertically and horizontally.
- Compare total events, directional buckets, the latest delta pair, and signed cumulative X and Y values.
- Repeat under the same browser and device settings, then select Reset test to clear the local session.
The dashed area is the only place on the page that intercepts wheel events for the tool. The page suppresses its own normal scrolling inside that zone so the target stays under your pointer while you compare directions, and wheel gestures outside the area continue to behave normally and are not counted. The area can also receive keyboard focus for a visible outline, but arrow keys are not treated as wheel input, and touch scrolling that does not generate wheel events will not appear in the buckets either.
Reading the Counts and Delta Values
Each wheel event arriving at the test zone produces four pieces of output. The total event counter increments by one for every accepted event. The dominant direction is decided by a transparent rule and added to one of five buckets. The latest raw delta pair shows the exact deltaX and deltaY values from the most recent event. The cumulative X and Y totals are signed sums that add the latest deltas to whatever is on screen.
| Inputs (deltaX, deltaY) | Label |
|---|---|
| (0, 0) | none |
| any, with |deltaY| ≥ |deltaX| and deltaY > 0 | up |
| any, with |deltaY| ≥ |deltaX| and deltaY < 0 | down |
| any, with |deltaX| > |deltaY| and deltaX > 0 | right |
| any, with |deltaX| > |deltaY| and deltaX < 0 | left |
Equal non-zero magnitudes always choose the vertical axis, which is why a perfectly diagonal gesture lands in either up or down rather than splitting into two buckets. Each event gets exactly one visible bucket by design; the rule does not imply that a diagonal movement contains motion on only one axis, only that the label describes the dominant one. A zero-delta event delivered by synthetic input or unusual browser handling is preserved in its own "none" bucket rather than silently discarded, and non-finite synthetic deltas are rejected before any counter is touched.
The cumulative totals are signed sums, which means opposite gestures subtract. A short worked example makes the behavior concrete. Start with cumulative X = 0 and cumulative Y = 0.
- Event 1 arrives with deltaX = -3 and deltaY = 5. The absolute values are 3 and 5, so vertical wins, and because deltaY is positive the event is labeled up. Cumulative X becomes 0 + (-3) = -3. Cumulative Y becomes 0 + 5 = 5.
- Event 2 arrives with deltaX = 4 and deltaY = -1. The absolute values are 4 and 1, so horizontal wins, and because deltaX is positive the event is labeled right. Cumulative X becomes -3 + 4 = 1. Cumulative Y becomes 5 + (-1) = 4.
The session now records 2 total events, 1 up, 1 right, 0 down, 0 left, 0 none, a latest delta pair of (4, -1), and cumulative totals of X = 1 and Y = 4. If a third event then arrived with deltaX = -1 and deltaY = -4, cumulative X would become 1 + (-1) = 0 and cumulative Y would become 4 + (-4) = 0 even though three events were clearly counted.
That cancellation is the reason the directional buckets and total count stay the better record of activity. The signed sums are useful for spotting drift over a long session, but a cumulative value near zero never means nothing happened. If you want a deeper read on what the figures represent and what they leave out, the guide on what the numbers mean walks through the same edge cases in more detail.
Why Wheel Deltas Look Different Across Devices
A single physical gesture can produce very different delta values on different devices, and the difference is not a bug. Browsers, operating systems, mouse drivers, wheel hardware, trackpads, accessibility software, and acceleration settings can all choose what unit a delta represents. One event may be expressed in pixels, another in lines, another in pages, and another in a browser-specific unit that has no published physical meaning. The tool intentionally does not convert any of those values to centimeters, wheel notches, or screen pixels traveled, because there is no honest conversion when the underlying unit is unknown.
A traditional vertical wheel usually generates only up and down events with consistent magnitudes for a given notch. Tilt wheels and most trackpads can add horizontal deltas, often with smaller magnitudes for the same physical pressure. Remote desktop software, accessibility utilities, and driver-level smoothing can combine multiple physical notches into a single event or split a single gesture into several smaller ones, which is why repeating the same movement twice can produce two different total counts. These are properties of the input pipeline between your hand and the page, not of the test itself.
Comparing the latest label with the gesture you actually made, then repeating the same gesture slowly and quickly, is the cleanest way to spot device-specific behavior. A traditional wheel often produces one event per notch with predictable magnitudes. A trackpad may deliver several smaller events for the same swipe, sometimes with combined deltas on both axes. If the buckets you expect do not appear, the most likely cause is the device or driver, not the tool.
What the Tool Does Not Measure
The tool is narrow on purpose. It does not measure USB polling rate, because the browser can throttle, combine, or skip wheel events before the page ever sees them, and event frequency is therefore not a reliable proxy for hardware polling. It does not measure input latency, the moment a wheel physically moved, hardware encoder bounce, radio quality, or driver health. It is not a hardware diagnostic, not a repair guide, and not an accessibility assessment. A missing direction in the buckets can come from device capability, browser interception, gesture settings, remote desktop software, or simply the way you moved during the session, and the test result alone does not point to a single cause.
For decisions that depend on hardware behavior, manufacturer diagnostics or qualified support are the right next step. The scroll test proves only what reached this browser target during the current session, not what every program or operating-system control will receive. If an application behaves differently, test there too; the page proves what this browser saw, not what another program will see when it sits in front of the same operating system.
Privacy and Local-Only Behavior
Every counter, bucket, delta pair, and cumulative total lives in the current tab. The widget does not upload gestures, does not save a history file, does not identify the device, does not request hardware permissions, and does not listen for events outside its own test area. Refreshing the page, closing the tab, or selecting Reset test clears the session and returns every count and total to zero. The reliable contract is narrow and worth keeping in mind: the tool records finite browser wheel deltas delivered to the zone, applies a disclosed dominant-axis classification, keeps transparent counts and signed sums, and never presents those browser values as calibrated hardware measurements. If you want a checklist of what stays on your device versus what leaves it, the guide on whether an online mouse scroll test is safe to use walks through the same privacy contract with a focus on what to verify before you start.