DeviceBenchFree online cursor test
Cursor test that draws the path your pointer really took
A cursor that skips leaves a visible break in its own trail, and that trail is what this field draws: every position your browser recorded, joined into a line, with the moments when reports stopped arriving marked in amber. Move the same distance across your mousepad slowly and then quickly and the page compares the two, because the extra screen distance the fast sweep covers is pointer acceleration — the reason a flick that felt identical to the last one lands somewhere else. No driver and no sensor is read here: a web page meets the pointer only after the operating system has already scaled it.
- 100% free
- No signup
- Every sample drawn
- Acceleration gain
- Breaks marked in amber
Sweep the pointer across this field.
Every position your browser recorded is drawn here. A break wider than four times your own median interval turns amber, and a pause of a quarter second starts a new stroke.
Pointer acceleration — fast versus slow
Sweep the same distance across your pad three times slowly, pause, then three times fast. So far: 0 slow, 0 fast.
- Slow sweeps
- 0 — median — px
- Fast sweeps
- 0 — median — px
- Gain
- —
Two ways to ask how far it moved
- Added up from clientX/clientY
- 0 px
- Added up from movementX/movementY
- 0 px
- Ratio
- —
- Device pixels per CSS pixel
- —
Chromium reports movement in device pixels and client coordinates in CSS pixels, so on a scaled display these two totals differ by exactly the ratio underneath them. Firefox and Safari keep both in CSS pixels.
A trackpad or a touch screen draws here too, but the acceleration figure means nothing on one: a gesture surface has a speed curve baked into the driver that no setting turns off. The field also stops at its own walls — the operating system pins the cursor at the edge of the display, and a sweep that ends against the wall is discarded rather than counted short.
How to test a cursor for stutter and acceleration
Two sets of sweeps and one look at the line. The second set is what makes the first one mean anything.
Sweep slowly across the field, then stop
A quarter of a second of stillness closes one stroke and opens the next, so you never have to take your hand off the mouse to record anything. After each sweep the line above the field tells you how long it was, how fast it peaked, and whether it was slow enough to count — repeat until three slow sweeps have registered.
Make the same sweep three times as fast as you can
The distance that has to stay the same is the one your hand covers on the mousepad, not the one the cursor covers on screen; the gap between those two is the whole measurement. Start each fast sweep from wherever the cursor happens to be and let it run out inside the field — a stroke that ends against a wall is thrown away rather than counted short, because the cursor stopped there while your hand kept going.
Read the gain, then look at what the line did
A gain near 1.00 means your pointer moves at a fixed ratio and fast aim lands where slow aim did. Above about 1.35 the pointer is being accelerated hard enough that no two flicks of the same length end in the same place. Then look at the drawing itself: amber segments are moments when reports stopped arriving, and the panel underneath says how far the cursor traveled during the worst of them.
Technical specifications
| What the trail cannot show | The sensor's own counts — a browser meets the pointer only after the operating system has scaled it |
|---|---|
| Positions drawn | Every uncoalesced pointer sample, at whatever rate your mouse reports them |
| Break rule | A gap longer than 4× your own median sample interval and at least 6 ms, drawn in amber |
| Stroke boundary | 250 ms of stillness closes a stroke; anything under 60 px or 15 ms is discarded as a nudge |
| Speed classes | Peak under 800 px/s counts as slow, over 2,500 px/s as fast; three of each are needed for a ratio |
| Peak speed window | 20 ms, so one stray 1 ms interval cannot define a flick |
| Strokes kept | The last 60, each with its length, duration and peak speed |
| Data kept | None — the trail is pixels on a canvas and the strokes are numbers, both gone on Clear |
Frequently asked questions
My cursor jumps across the screen. What causes that?
The trail tells you which of three very different faults you have. A break drawn in amber, with a real time gap behind it, means reports stopped arriving for a moment — a wireless dongle fighting a USB 3 port for the 2.4 GHz band is the usual culprit, followed by a machine so busy it missed its own deadlines. Short erratic zigzags while your hand moves straight are the sensor losing the surface, which happens on glass, on high-gloss desks and on a lens with a hair across it. An unbroken line that ends somewhere you did not aim is neither: something else moved the pointer, such as a driver option that snaps it onto the default button of a dialog.
What is pointer acceleration, and how do I turn it off?
It is a curve that converts how fast your mouse is moving into how far the cursor goes, so the same physical sweep covers more screen when you do it quickly. On Windows it is the Enhance pointer precision checkbox under Mouse Properties, Pointer Options, and unticking it gives you a fixed ratio. On macOS there is no switch in the interface at all: the tracking slider adjusts the curve rather than removing it, and turning it off means writing com.apple.mouse.scaling as -1 in the global preferences and logging out, or installing a utility that does the same. On Linux, libinput calls the setting a pointer-acceleration profile and the fixed option is named flat.
The trail looks smooth but my mouse feels jerky. Which do I believe?
Both, because they answer different questions. This drawing uses every position the browser recorded, including the ones it bundled together before handing them over, so the line is as smooth as the hardware was. What you feel is when those positions reach the screen, which is a matter of how often the mouse reports and when a frame lands — the polling rate test counts the reports and explains why the raw event count is not the same number.
Why does the trail stop at the edge of the field?
Because the page only listens inside that box, and the operating system pins the cursor at the edge of the display for the same reason. It matters more than it looks: while the cursor is stuck against a wall your hand is still moving, so any stroke that touched a wall is excluded from the slow-versus-fast comparison instead of being recorded as a short one. Give a fast sweep room to finish inside the field and it counts.
The two distance totals disagree with each other. Which one is right?
Both are, and the ratio between them is a browser fact rather than a mouse fault. Client coordinates are always in CSS pixels; Chromium fills movementX and movementY in device pixels, so on a display running at 150% or 200% scaling the movement total comes out larger by exactly that factor, and browser zoom moves it the same way. Firefox and Safari keep both in CSS pixels and the ratio sits at 1.00. The one case where movement genuinely carries information the coordinates cannot is pointer lock, which games use: the cursor is hidden and pinned, client coordinates stop changing, and movement keeps counting.
My slow and fast sweeps give a gain of 1.00. Is the test broken?
That is the result you want, and it means your pointer is running at a fixed ratio with no acceleration in the path. Two things can fake it, though. If your slow and fast sweeps were not far apart in speed, both landed in the same class and the comparison never happened — the readout says how many of each it has. And if your hand covered different distances on the pad for the two sets, the ratio is measuring your arm rather than the driver.
Does this work on a laptop trackpad or a touch screen?
The trail does and the gain does not. A trackpad or a glass panel has a speed curve built into its gesture driver that no operating system lets you disable, so a fast flick will always cover more distance and the ratio has nothing to say about it. The drawing is still useful there for a different reason: a dead strip under a trackpad or a digitizer that loses contact shows up as a break in exactly the same way, and the touch screen test lays out the same idea for several fingers at once.
About pointer acceleration and what a browser sees of it
Between the sensor and this page there are four stages, and a browser is only present for the last one. The sensor counts surface movement and reports it at a fixed interval; the operating system converts those counts into pointer movement through a transfer curve; the compositor puts the cursor somewhere; and only then does a pointermove event carry clientX and clientY to the page, in CSS pixels, already scaled. That is why no web page can tell you a DPI or a firmware setting, and why the honest thing to measure here is the relationship between two of your own movements rather than an absolute number. movementX and movementY ride along on the same event as the delta since the previous one — useful, but not a second opinion: Chromium fills them in device pixels while the coordinates stay in CSS pixels, so the totals part company on any scaled display.
The transfer curve is the interesting stage. Windows calls its version Enhance pointer precision and switches it on by default; it maps counts per millisecond onto pixels through a lookup table, so moving the mouse twice as fast moves the cursor more than twice as far. That is genuinely helpful for hitting a menu on a large display and genuinely ruinous for aim, because the same 15 cm sweep across a pad now ends in a different place depending on how quickly you did it. This page cannot read the curve — no web API exposes it — but it can measure its effect, which is what the slow and fast sets are for. Anything within about 10% is your own hand and not a driver; a fast set that lands consistently further out is the curve doing its work. If you are chasing a number rather than a feel, the mouse DPI test is the page that turns a measured drag into counts per inch, and it is only meaningful once the gain here reads 1.00.
“My cursor jumps” describes three unrelated faults, and the drawing separates them. Reports that stop arriving leave an amber break with time behind it, which points at wireless interference or a machine under load rather than at the mouse. A pointer that moves when your hand does not is usually software: a driver setting, a second input device resting under a sleeve, or a touchpad the palm is brushing. And a cursor that leaves copies of itself smeared across the desktop is not a pointer fault at all — that is the display failing to repaint, which you can confirm in ten seconds by filling the panel with black or white and seeing whether the smear survives with nothing else on screen. Once the path is clean, the remaining mouse questions are how often it reports, which the polling rate test counts, whether the switches still fire, which the mouse test walks through, and whether the panel under your fingers tracks properly, which is the touch screen test.
Where the trail is drawn
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
The path exists in two places, both of them inside this tab: as pixels on a canvas, and as a short list of stroke lengths waiting to be compared. Clearing the field destroys both at once, and no record of where you pointed or what you were pointing at is kept for anything to reconstruct.