Mouse DPI Analyzer

How to use it, and how to read the result

1. Kill acceleration first. Follow the box at the top of the page. If the panel says raw pointer input is active you can skip it, but the pointer-speed slider still has to be on the middle notch for the fallback mode.
2. Mark a distance on your mousepad. Two strips of tape, two pen marks, a ruler laid alongside — anything you can start and stop against precisely. No ruler? A bank card is exactly 3.370 in / 85.60 mm wide; lay it end over end and use the card-width presets.
3. Pick that distance in step 2. Longer drags are proportionally more accurate: an eighth of an inch of sloppiness is 3% over 4 in but only 1.2% over 10 in.
4. Click the pad to lock the pointer. The cursor disappears — that is the point. Nothing can clamp your movement at the edge of the screen any more.
5. Put the mouse on the start mark, then press Space. Space is better than clicking: pressing a mouse button nudges the sensor a few counts. Drag straight to the end mark in one smooth motion without lifting, then press Space again.
6. Do it at least three times. The tool shows every take, the mean and the spread. A spread under ±1% means you can trust the number. Above ±3%, something in the chain is still wrong — read the take warnings.
7. Compare with the box. Type in the DPI your mouse is set to. Under 3% deviation is normal manufacturing variance; over 10% is worth acting on, because it scales your sensitivity in every game you play.
8. Press Esc to release the pointer when you are done.

What is actually being measured

A mouse sensor is a tiny camera. It photographs the surface a few thousand times a second, works out how far the texture shifted between frames, and reports that shift to the PC as a whole number of counts. DPI — more correctly CPI, counts per inch — is how many of those counts the sensor emits per inch of physical travel. It is a property of the sensor and its firmware, and it has nothing to do with your monitor, your resolution or your game.

So the measurement is trivially simple in principle: move the mouse a known number of inches, add up the counts, divide. Everything hard about it lives in the two links of the chain between the sensor and this page.

Link one: the operating system rewrites the numbers

Counts do not reach the browser untouched. The OS pointer pipeline scales them first. On Windows the pointer-speed slider is a straight multiplier and only the middle notch is 1:1 — the notches below it shrink your movement (down to a thirty-second) and the ones above multiply it (up to 3.5×). Get that wrong and your DPI reads exactly that factor off.

Enhance pointer precision is worse, because it is not a constant. It is a velocity curve: move slowly and a count is worth less than a pixel, flick and it is worth several. The counts you accumulate then depend on the speed of your swipe, so two careful drags over the same 4 inches will disagree by 10–20%. That is the classic symptom of a wide spread in the takes list.

There is a way out of the whole mess. Chromium browsers can request pointer lock with unadjustedMovement: true, which hands the page the raw HID deltas straight from the device — no speed multiplier, no acceleration curve, no display scaling. When the panel above reports raw input active, none of the OS settings matter and the counts you see are literally the counts the sensor emitted. Firefox and Safari do not implement it, so on those browsers the tool falls back to the OS-processed path and labels the result an estimate.

Link two: the pixel-unit trap that makes most DPI tools wrong

In the fallback path the browser reports movement in CSS pixels, and a CSS pixel is not a device pixel. At 150% display scaling one CSS pixel is 1.5 device pixels, and it is device pixels the cursor actually moves in. A tool that treats the reported movement as counts therefore under-reports by exactly 1.5× on that machine — you set a 1600 DPI mouse and it confidently tells you 1067. On a Retina Mac the same class of bug goes the other way. This is why so many DPI checkers give people numbers they know are wrong, and why the page shows you the scale factor it applied instead of hiding it.

The tool resolves the unit two ways. Before you lock the pointer it silently compares the reported movement against the cursor's travel in layout coordinates, which are unambiguously CSS pixels, and snaps the ratio to whichever of 1 or your display scale it matches. On macOS it knows the pointer moves in points rather than backing pixels and applies no scaling at all. If it guesses wrong you can override it under Advanced · movement scale — and a result that jumps by exactly your display scale when you flip that switch is the tell.

Where honesty costs something, here is the bill. That unit sample can only be taken while the pointer is free, because a locked pointer stops moving layout coordinates altogether — there is nothing left to compare against. Browser engines are known to report locked deltas in a different unit from unlocked ones, so on a scaled display the sample is the best available assumption for the locked measurement rather than proof of it. Two things make this a non-issue in practice: raw pointer input sidesteps the question entirely, and if your display scale is 100% there is no ambiguity at all, because a CSS pixel and a device pixel are then the same size. If you are on a 125% or 150% laptop panel and the answer looks like your advertised DPI multiplied or divided by exactly that, you have found the switch you need — the page says as much on screen rather than quietly picking for you.

Why the credit card is on the screen and not just on the desk

Be clear about this, because a lot of tools are not: screen pixel density cancels out of the DPI equation. Counts divided by inches of desk travel is the whole calculation, and how many pixels per inch your monitor has never enters it. What the card calibration buys you is everything around the number — a ruler on this page that is genuinely true to size, your display's real pixel density instead of the 96-per-inch fiction the web assumes, and the cursor-gain figure that tells you how far your hand has to move to cross the monitor. The card itself is also the best ruler in the room: every bank card, ID card and driving licence on earth is an ISO/IEC 7810 ID-1 card, 85.60 mm wide to a tolerance of a tenth of a millimetre.

What a bad result looks like, and what to do

• Takes disagree by 5–20%, faster drags reading higher. Acceleration is still on. Recheck Enhance pointer precision — some gaming mouse drivers re-enable it, and a few games reset it on exit.
• Every take is off by a clean 2×, 1.5× or 0.5×. That is a scale factor, not a bad sensor: the pointer-speed slider is off the middle notch, or the movement scale needs the override in Advanced.
• The path-length warning keeps firing. Your drag is curving. The tool measures the straight line between where you started and where you stopped, so a banana-shaped swipe reads short. Slide the mouse along a ruler edge.
• Counts drop out mid-drag on a mousepad you like otherwise. Glass, gloss, plain white and very dark surfaces defeat optical sensors, and lifting the mouse even a millimetre mid-swipe silently loses counts. A cloth pad fixes both.
• Measured DPI is a tidy number the mouse does not offer. Plenty of sensors only expose steps of 50 or 100 and round in firmware; the underlying value can sit a few percent away from the label.
• Deviation over 10%. Real, and worth correcting. Your effective DPI is what actually drives aim, so raise or lower the in-game sensitivity by the same percentage to land back where you expect — or use your mouse software to pick a step that measures closer to the target.

One more honest limit: the tool's arithmetic is exact but your ruler is not. Over a 4 inch drag, being an eighth of an inch out at either end is a 3% error, which is larger than the deviation most sensors have. The uncertainty printed with the result is the spread across your takes only — it cannot see how well you measured the desk.

Related tools