Skip to content
DeviceBench

Free online mouse DPI test

Mouse DPI test from one measured drag

Mark two points a known distance apart on your mousepad, drag the pointer from one to the other across the track below, and the page divides the pixels it counted by the inches your hand moved to give counts per inch. The number is derived rather than read: nothing in a browser can interrogate a sensor, so what comes out covers the whole chain from the mouse to the pointer, and it equals the figure on the box only when acceleration is off and the pointer-speed slider sits at its 1:1 notch. Three drags produce three readings, and the spread between them is the honest error bar on the method.

  • 100% free
  • No signup
  • Counts per inch
  • cm or inches
  • Spread across up to 8 runs

Mark two points on the pad that far apart before you drag — a strip of tape, or the long edge of a payment card, which is 8.56 cm on every card ever issued.

Press the button here, at the line on the left

Hold it down and drag the mouse the marked distance across the pad, slowly, in one straight pull. The drag keeps counting past the edge of this box, so let it run — it is only the pad distance that has to match.

Measured resolution

Nothing measured yet. One drag gives a number; three give you the spread between them, which is the only honest error bar this method has.

Before the number means anything

  1. Acceleration off. With a transfer curve in the way the pointer covers extra ground on a quick pull, so the same mouse reads high or low depending on how you dragged. Runs above 4 in/s are refused here for that reason, and the cursor test both measures the gain and names the switch on each operating system.
  2. Pointer speed at its middle notch. On Windows the slider under Mouse Properties multiplies cursor movement by anything from 1/32 to 3.5; only the sixth of its eleven positions is 1:1, and every other one scales the answer by exactly that factor.
  3. Zoom left alone. Reading this display’s pixel ratio… Browser zoom and display scaling both move that number, and each run stores its own copy so a change mid-session is caught rather than averaged in.

Nothing here reads the mouse. The page counts pointer travel and divides it by a distance you measured with your own hand, so the accuracy of the answer is the accuracy of that measurement: 2 mm of slop over a 10 cm drag is 2% of the result, which is why the run table stays visible and the spread matters more than any single figure.

How to measure mouse DPI

One distance you measure, one drag the page measures, and a third run to prove the first two.

  1. Mark a distance on the pad, not on the screen

    Put two marks 10 cm apart on the mousepad — a strip of tape at each end, or the long edge of a payment card twice, which is 8.56 cm every time because ID-1 is a manufacturing standard. Type that distance into the field and pick the unit. It has to be the distance the mouse body travels across the surface; the distance the cursor covers on screen is the other half of the division and the page is already counting it.

  2. Press at the left line and pull once, slowly, in a straight line

    Hold the button down with the mouse on the first mark and drag to the second in one steady pull, taking at least two and a half seconds over 10 cm. Slow is not politeness: above 4 inches of pad per second the operating system's transfer curve starts adding distance the sensor never reported, and runs above that are refused rather than recorded. Release while the mouse is still moving, and keep the cursor away from the edge of the display — once it is pinned against a wall your hand keeps going and the pointer does not.

  3. Do it three times and read the spread before the number

    Each run is listed with the pad distance and pixel ratio it was measured at, and the headline figure is the median of them. A spread under about 3% means the three runs agree and the median is worth quoting; a spread above 6% means something is still scaling the pointer between your hand and the page, and no amount of averaging will fix it. When the reading lands within 10% of one of the sixteen steps mice are advertised at, the page names that step — 1,592 CPI is a 1600 DPI mouse.

Technical specifications

What the browser cannot readThe sensor. No web API exposes a mouse resolution, so the figure is pointer travel divided by a pad distance you measured, which includes the operating system's pointer scaling as well as the sensor
Pixels countedStraight-line displacement between press and release, rebuilt from getCoalescedEvents() so a 1,000 Hz mouse loses nothing to frame bundling
Pixel unitCSS pixels × devicePixelRatio on Windows, X11 and ChromeOS; CSS pixels alone on macOS and iPadOS, which move the pointer in points rather than display pixels
Shortest drag accepted200 CSS px — below that a single pixel of rounding is more than 0.5% of the answer
Hand speed ceiling4 inches of pad per second, computed from your distance and the drag's duration; faster runs are refused rather than recorded
Straightness ruleA traced path more than 5% longer than its straight line is rejected, because a curved drag cannot match a straight measurement on the pad
Advertised steps matched16 values from 400 to 26,000 DPI, named when the reading falls within 10% of one
Data keptNone — up to 8 pixel counts, their durations and one distance you typed, all discarded on Clear runs or a reload

Frequently asked questions

The reading is nowhere near the DPI I set. What is wrong?

On Windows it is almost always the pointer speed slider, and the ratio tells you which notch it is on. That slider multiplies cursor movement by a fixed factor — 1/32, 1/16, 1/8, 1/4, 3/8, 1, 1.5, 2, 2.5, 3 and 3.5 across its eleven positions — and only the sixth is 1:1. So a 1600 DPI mouse reading 2,400 is sitting on position 7 and one reading 600 is down on position 5, and in both cases the fix is to put the slider back to the middle and measure again rather than to distrust the mouse. macOS has no equivalent notch: its tracking slider bends the curve rather than scaling it, which is why a Mac reading is only trustworthy once acceleration is off entirely.

Is DPI the same thing as CPI?

They are the same quantity and CPI is the correct name for it. A mouse sensor photographs the surface thousands of times a second and reports how many counts of movement have happened since the last report, so its resolution is counts per inch. Dots per inch came from printing, where a dot is a spot of ink on paper and a mouse produces none. Vendors print DPI on the box because that is what people search for, and this page follows the box in its title and the sensor in its readout.

Why did the number change when I zoomed the browser or changed display scaling?

Because both of them change what a pixel is, and the page has to convert. Coordinates in a browser arrive in CSS pixels, and devicePixelRatio is how many display pixels one of those covers — it moves with display scaling and with browser zoom alike, so at 150% a drag that reports 1,066 CSS pixels really crossed 1,600 of them. Windows, X11 and ChromeOS move the pointer in display pixels, so that multiplication is the right one there; macOS and iPadOS move it in points, so on those the unconverted CSS figure is the count and multiplying would double it. Each run stores the ratio it was measured at, and a session where the ratio changed part way through is flagged instead of averaged.

My three runs disagree by 15%. Which one do I believe?

None of them — a spread that wide means something is still scaling the pointer, not that one run was unlucky. Acceleration is the usual cause, because it makes the answer depend on how fast each pull was rather than how far it went, and the cursor test will tell you in one sweep whether a curve is in the path. The other cause is the pad measurement moving: if the mouse started a centimeter short of the mark on one run, that is 10% of a 10 cm drag on its own. Tape the marks down, redo three runs at a crawl, and expect the spread to fall under 3%.

My mouse has no software and nothing printed on it. Can I still find its DPI?

That is the case this page exists for. Office mice ship at 800 or 1,000 CPI and almost never say so anywhere on the device or in the manual, and there is no operating system dialog that reports it — Windows and macOS both show you a speed slider, which is a multiplier applied afterwards, not the sensor's resolution. A drag here gives you the number without installing a vendor utility, and without registering anything: the measurement is arithmetic in the tab, so there is no account and no driver involved.

Does the mousepad surface affect the result?

It can, and it shows up as a reading that comes out low rather than as an obvious failure. An optical sensor that briefly loses the surface stops reporting counts, so the pointer covers less ground than your hand did and the division under-reports. Glass, high-gloss desks, mirror finishes and very dark cloth are the usual offenders, along with a lens with a hair across it. If the number rises when you move to a cloth pad, the pad was the problem; if the pointer also drew visible zigzags while your hand went straight, that is the same fault seen from the other side.

Why does the page refuse a fast drag?

Because a fast drag measures your acceleration curve rather than your sensor. Windows' Enhance pointer precision and macOS' default curve both map speed onto extra distance, so the same 10 cm across the pad produces more pixels when you do it quickly, and the faster the pull the more of the answer is curve. Four inches of pad per second is the ceiling here — 2.5 seconds for a 10 cm drag — which is slow enough that every curve worth worrying about is still in its flat region. A slow pull also gives the mouse time to report the whole path instead of a coarse sample of it.

About DPI, CPI and the division behind the number

A mouse sensor is a very small camera. It photographs the surface underneath it thousands of times a second, compares each frame with the last, and reports how many counts of movement have happened since it last spoke. Its resolution is therefore counts per inch, and CPI is the correct name for the quantity every box calls DPI — dots per inch belongs to printing, where a dot is a spot of ink and a mouse produces none. The distinction stops being pedantry the moment you go looking for the number: the sensors in current mice step in 50 CPI increments all the way to 26,000, so the round figures people quote are firmware presets someone chose, not anything the hardware is limited to. That is also why this page names the nearest advertised step instead of insisting on it. A reading of 1,592 is a 1600 DPI mouse; a reading of 1,180 is a 1200 DPI mouse with a 2 mm error in how you marked the pad.

The whole measurement is one division, and both sides of it carry error worth knowing about. The distance your hand moved is the side you supply, and it is a hand measurement: 2 mm of slop over a 10 cm drag is 2% of the answer, which is why the marks want tape rather than memory and why the page keeps every run visible instead of collapsing them into one confident figure. The pixel side is counted exactly but in the wrong unit, because a browser reports coordinates in CSS pixels and a CSS pixel is not a display pixel whenever the display is scaled or the page is zoomed. Multiplying by devicePixelRatio converts it, which is right on Windows, X11 and ChromeOS, where the pointer is moved in display pixels — and wrong on macOS and iPadOS, where it is moved in points and the conversion doubles the answer on a Retina panel. That single platform split is why two DPI analyzers can disagree by a factor of two about the same mouse, and it is the same absence of a real length unit that makes the screen ruler ask you to hold a payment card against the glass before it will show a millimeter.

None of this survives pointer acceleration, which is the one prerequisite worth checking before you drag anything: with a curve in the path the ratio depends on how fast you pulled rather than how far, and the cursor test measures whether one is there and names the switch on each operating system. Once you have a trustworthy CPI, the thing to do with it is convert it: aim consistency lives in centimeters per 360° turn, not in DPI, and the mouse sensitivity converter carries the same physical turn between games whose sensitivity scales disagree, working out eDPI along the way. Two things a higher CPI is not: it is not sharpness, since the extra counts are usually divided straight back out by an in-game multiplier, and it is not speed — how quickly a movement reaches your computer is the report rate, which the polling rate test counts. A mouse with a correct CPI that still feels wrong usually has a mechanical fault instead, and the mouse test walks the buttons.

What the drag leaves behind

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.

Two numbers per run outlive the drag: how many pixels the pointer covered and how long it took. The positions those pixels were made of are folded into a running total as each sample arrives and then dropped, so nothing on this page could say where on the screen you dragged even while you are dragging, and Clear runs empties the totals as well.