A browser mouse scroll test measures the wheel events that reach the page, classifies each one by direction, and shows the raw horizontal and vertical deltas the browser reports — it does not return a calibrated distance or a hardware specification. Accuracy in this context means the test reliably catches what your wheel or trackpad sent to the browser during the session, and it is precise about which axis dominated each gesture. It is not a measurement of millimeters traveled, USB polling frequency, or input latency, because the browser can combine, smooth, accelerate, or suppress wheel events before any page sees them. Use the totals and directional buckets as a record of activity, use the raw delta pairs to compare gestures of similar feel, and treat signed cumulative values as a running tally rather than a distance reading. That framing is what makes scroll test results interpretable instead of misleading, and it is the difference between reading the page and reading the wheel.
Scroll wheels and trackpads feel consistent in the hand yet can produce very different delta values on the same gesture, which is why "accurate" needs a careful definition before any number is trusted. The Mouse Scroll Test gives you the raw browser data plus a transparent classification rule, so you can tell whether the issue is the device, the driver, the browser, or your test method rather than guessing at the wheel itself.
What Mouse Scroll Test Accuracy Actually Means
Three things have to be accurate for a scroll test to be useful: the test has to count every wheel event the browser delivered, it has to label each event the same way every time, and it has to preserve the raw magnitudes without quietly converting them into something else. The Mouse Scroll Test is designed around that contract. It accepts finite WheelEvent deltaX and deltaY values only inside a visible dashed zone, increments a total counter and one directional bucket per event, stores the latest raw pair, and adds signed deltas to two cumulative totals. Non-finite synthetic deltas are rejected and counter overflow is guarded, so the displayed values are never a rounding artefact of internal arithmetic.
Accuracy here is not the same as calibration. A delta from a WheelEvent can represent pixels, lines, pages, or another browser-defined unit depending on the event source. Two devices that feel identical under your finger can produce very different numbers on screen, and that gap is a property of the browser and operating system pipeline, not a defect of the wheel or of the test. Treat the totals and bucket counts as a faithful record of what reached the page during the session, and treat the raw delta pairs as the browser's own description of each event.
| What the test records | What the test does not measure |
|---|---|
| Total wheel events delivered to the zone | USB polling rate |
| Directional bucket (up, down, left, right, none) | Calibrated physical distance |
| Latest raw deltaX and deltaY pair | Input latency or timing |
| Signed cumulative X and Y totals | Hardware health, encoder quality, or radio signal |
| Zero-delta events, kept in their own bucket | A cross-device normalized score |
Run the Scroll Test and Read the Numbers
The workflow is short on purpose. Each step is something the page can show you directly, and repeating it under the same browser and device settings is what turns a single run into a meaningful comparison.
- 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 zone exists for a reason. Wheel events delivered to it do not trigger the page's normal scrolling, which keeps the target in place while you compare directions. Gestures outside the zone behave normally and are not counted at all, so make sure the pointer stays inside the dashed boundary for every event you want included in the totals. The area can receive keyboard focus for a visible outline, but keyboard arrow keys are not treated as wheel input, so they will not move any counter.
How Each Direction Bucket Is Chosen
Each wheel event lands in exactly one of five visible buckets, and the rule is deliberate so the same gesture always maps to the same label. The full rule is small enough to fit in a table.
| Situation | Label |
|---|---|
| deltaX and deltaY are both zero | none |
| |deltaY| ≥ |deltaX| and deltaY is positive | up |
| |deltaY| ≥ |deltaX| and deltaY is negative | down |
| |deltaX| > |deltaY| and deltaX is negative | left |
| |deltaX| > |deltaY| and deltaX is positive | right |
| Equal nonzero magnitudes on both axes | up or down by the sign of deltaY |
Equal magnitudes always choose the vertical direction, which means a gesture that felt diagonal will only appear in one bucket. That is a display choice, not a claim about the gesture — diagonal scroll input can absolutely contain movement on both axes, but the test shows one label per event so the buckets stay readable. If a direction appears missing, the rule above is the first place to look before suspecting the device. A traditional vertical wheel will usually generate only up and down events, while tilt wheels and trackpads may also produce horizontal deltas.
Why Cumulative Values Can Read Near Zero
The cumulative X and Y totals are signed sums. Every positive deltaX adds to the X total, every negative deltaX subtracts from it, and the same is true for Y. That makes the cumulative numbers a running net rather than a total distance, so opposite gestures cancel each other out.
A cumulative Y near zero does not mean the wheel stayed still during the session. It means the up deltas and the down deltas roughly balanced. The total event count and the up and down directional buckets will still reflect that activity, which is why the directional counts are the better record of whether the wheel actually moved. Use cumulative values to spot drift in one direction across a long session, and use the directional counts to confirm that movement happened at all.
What Can Keep a Direction From Appearing
There are several reasons a direction can be absent from the buckets, and most of them are not defects. A traditional vertical mouse wheel simply does not generate horizontal deltas, so left and right buckets will stay empty until you switch to a tilt wheel, a trackpad, or a device that exposes horizontal scrolling. A browser can also intercept wheel events before the page sees them, which is common when smooth scrolling, accessibility zoom, or page-level shortcuts are active. Gesture settings, remote desktop software, and certain drivers can collapse or rewrite events before they arrive.
Touch scrolling on a trackpad only counts if it generates wheel events. Some operating systems and browsers treat trackpad gestures as inertial panning rather than discrete wheel events, and those will not appear at all. If you suspect a missing direction, run the same gesture two or three times in the same browser session and watch whether the total event count moves. A flat total with no bucket change usually means the events never reached the page; a moving total in the expected bucket means they did, and the device or driver is sending what the browser expects.
What This Tool Cannot Diagnose
Scroll test accuracy has a narrow scope and it is worth keeping that scope in mind. The page records what the browser delivered to the zone during the session. It does not measure USB polling frequency, hardware encoder bounce, radio quality, driver health, or the exact moment a wheel physically moved. Browser wheel events can be combined, smoothed, throttled, or accelerated before the page receives them, so event frequency and delta magnitudes cannot be treated as raw hardware signals.
For hardware decisions, manufacturer diagnostics and qualified support are the right next step when the browser-level test is inconclusive. For browser-level decisions, the test is enough: it tells you whether wheel events arrive, in which directions, with what magnitudes the browser chose to report, and whether they sum to a stable or drifting net over the session. Reset clears the local session, refreshing the page does the same, and no data leaves the tab, so repeated runs start from a clean slate every time.