Methodology · the thesis, the arithmetic and the blind spots
What this ruler measures, how it is kept, and where it stops
This is the site's own account of itself. It sets out the one thing that is measured, the arithmetic that turns it into every number the instruments print, and then — at greater length, deliberately — the things this site cannot do, cannot see, and will not claim. The order is not decoration. A measuring tool is only worth what its limits are worth, and the limits here are longer than the claims because that is the true shape of the subject.
What is measured, how it is kept, and what it cannot tell you
What is measured. One ratio, and nothing else: how many of your display's pixels a millimetre of glass covers. That number cannot be obtained from the browser, because no browser is told the physical size of the panel it is drawing on, so it comes from you — an object whose dimensions a published standard fixes, held against the screen, with an outline dragged until the two agree. Every millimetre, inch and fraction any instrument on this site prints is arithmetic from that single ratio, and the marks are placed at their exact fractional pixel positions rather than snapped to whole pixels, because snapping moves a mark by up to half a pixel and half a pixel is 0.13 mm.
How it is kept. As device pixels per millimetre — the panel's own density — rather than as the CSS-pixel figure that varies with zoom, together with a snapshot of what the display was reporting when the match was made. On the next visit that snapshot is compared against the display as it is then. A pixel-ratio change is arithmetic the stored quantity absorbs, so it is corrected and the correction is named in the readout. Anything the comparison cannot absorb drops the readout out of green into a neutral state that says which thing changed. Nothing is sent anywhere: the policy served with this site permits the page to talk to no outside origin at all, so that is enforced by your browser rather than asserted in a sentence.
What it cannot tell you. Whether the screen in front of you is the screen you calibrated on, if the two report the same resolution; whether you picked up the object you told it you were holding; and whether anything between the page and the glass — a cast, a mirror, a magnifier — is changing the size of what you see. None of those three leave a signal for a web page to read, so none of them can be detected, and the whole of the section below exists to say so in detail rather than to leave it inferred from a confident-looking page.
What this site claims
Four claims, and they are the entire set.
- A calibrated reading is the ratio you gave it, applied honestly. When the readout is green, a centimetre drawn on your screen is a centimetre of glass to within the band printed beside it, on this display, in this browser, until something changes.
- The band is derived from the reference actually used. It is not a constant and not a house figure: it is the object's own permitted spread plus a fixed bound on human alignment, added as bounds, computed per object and per edge.
- A mark this display cannot resolve is reported, never drawn. Marks sit at their exact fractional positions, and a graduation level whose pitch falls below three device pixels is dropped with the level named and the density that would have kept it printed underneath.
- Nothing leaves your device. One record in your own browser's storage, holding a density, an object name and a snapshot of display measurements. No accounts, no analytics, no uploads, nothing that could be sent because there is nowhere to send it.
Everything below is what those four sentences do not cover. It is the longer half of this page, and that is the intended proportion rather than an accident of drafting.
How a calibration is taken
The reference is a bank card, an ID card or a driving licence — one object under three names, all of them ISO/IEC 7810 format ID-1 at a nominal 85.60 by 53.98 mm. You lay it on the glass and drag an outline until the edges agree, and the tool divides: the matched width in CSS pixels over 85.60 mm gives pixels per millimetre. The outline's travel runs from 129 to 1369 CSS pixels across the long edge, which is 1.5 to 16 pixels per millimetre, and that range is chosen to cover a living-room television used as a browser at one end and a 13-inch 4K laptop at 100% scaling at the other. An outline pinned at either rail is refused rather than badged, because a control that has run out of travel is telling you the input is implausible.
The control's step is derived from the object's length rather than fixed, so that one step is never worth more than 0.35% of the thing being matched. On a card at a typical desktop density that is a single pixel, or 0.31%. A shorter reference would need a finer step to keep the same relative resolution, and that is one of several reasons short objects make poor references.
The edge you match and the direction you hold it are separate choices. The edge is a length, and it sets the band. The orientation is which way the length runs across the glass, and it changes no arithmetic at all — it changes which options physically fit, which is the entire point on a phone, where 85.60 mm does not fit across a portrait screen but fits easily down it.
The band, in full
Every band on this site is one formula with no adjustable term:
band% = object tolerance% + (0.7 mm / reference length in mm) × 100
The first term is read out of the standard that governs the object. The second is the alignment allowance: 0.7 mm of combined slop across the two edges you line up, applied identically to every reference, so that the difference between two references comes only from their lengths and their published tolerances and never from a per-object judgement call. The two are added rather than combined in quadrature, because a ± sign reads as a bound and a bound is what is being stated; combining them in quadrature and then expanding the result to comparable coverage gives a larger number than the plain sum, so the tidier-looking method is also the worse one.
| Reference and edge | Nominal | Object tolerance | Alignment slop | Printed band |
|---|---|---|---|---|
| Bank card, long edge | 85.60 mm | 0.351% | 0.818% | ±1.2% |
| Bank card, short edge | 53.98 mm | 0.371% | 1.297% | ±1.7% |
| A4 sheet, long edge | 297.00 mm | 0.673% | 0.236% | ±1.0% |
| A4 sheet, short edge | 210.00 mm | 0.952% | 0.333% | ±1.3% |
The short edge of a card is the interesting row. The same 0.7 mm of hand slop is 1.59 times larger as a share of 53.98 mm than of 85.60 mm, so choosing the short edge costs half a percentage point of band, and the tool prints the wider number instead of a sentence about it being slightly less good. That is the general rule here: where an option is worse, it is worse by a stated amount.
What an uncalibrated screen actually shows
CSS defines an inch as exactly 96 pixels, and a millimetre as 96/25.4 = 3.7795 pixels, by definition rather than by measurement. No shipping browser resolves those units against real display geometry, because no browser has the geometry: there is no interface that reports the physical size of a screen. The often-repeated claim that physical units "become real" on high-density devices is an artefact of how the specification describes its anchor unit, not a behaviour anything implements. So an uncalibrated on-screen ruler is not a ruler with a small error. It is a ruler whose error is whatever the gap happens to be between your panel and 96 pixels per inch.
| Display | Panel density | Pixel ratio | CSS px per real inch | A CSS inch renders as |
|---|---|---|---|---|
| 24-inch 1920×1080 | 91.8 ppi | 1 | 91.8 | 1.046 in (+4.6%) |
| 27-inch 2560×1440 | 108.8 ppi | 1 | 108.8 | 0.88 in (−12%) |
| MacBook Pro 14-inch, default scaling | 254 ppi | 2 | 127 | 0.76 in (−24%) |
| 13.3-inch 1920×1080 at 100% | 166 ppi | 1 | 166 | 0.58 in (−42%) |
| iPhone 15 | 460 ppi | 3 | 153 | 0.63 in (−37%) |
| Pixel 7 | 416 ppi | 2.625 | 158.5 | 0.61 in (−39%) |
| 15.6-inch 4K at 100% | 282 ppi | 1 | 282 | 0.34 in (−66%) |
Two things follow. The errors are large enough to matter for everything anyone actually measures — a ring, a bolt, a picture frame, a parcel — and they do not run in a consistent direction, so no correction factor rescues them. And they are invisible: a ruler drawn at 96 pixels per inch looks exactly like a calibrated one. That is why every instrument here prints its calibration state beside the reading rather than letting a finished-looking page imply it, and why the uncalibrated state is neutral in colour rather than red. An uncalibrated ruler has not failed. It is simply not yet what it will be.
None of this applies to measuring something that is itself on the screen — an image, a button, a gap in a layout. That is a layout distance rather than a physical one, it is exact in CSS pixels with no calibration at all, and it has its own instrument that says so in its own readout.
How a calibration is kept
The stored quantity is not the number the ruler draws with. What is stored is the panel's density in device pixels per millimetre:
D_phys = ppmm_css × devicePixelRatio, and on any later visit ppmm_css = D_phys / devicePixelRatio.
The reason is that the browser's pixel ratio moves for both of the things that would otherwise destroy a calibration. Page zoom multiplies into it on Chrome, Edge and Firefox, and so does an operating-system display-scaling change on Windows and on GNOME. Dividing by the current ratio recovers the density that was measured, so both survive as arithmetic rather than as a stale number quietly drawn at the wrong size. That was measured rather than assumed: one calibration, four operating-system display scales, and a 100 mm span rendered as 378.5 device pixels at every one of them.
Stored alongside the density is a record of what the browser was reporting at the time — pixel ratio, native pixel count, browser chrome width and height, viewport width in device pixels, layout scale, pinch scale, the measured width of a CSS inch, and, where a mouse has moved, the ratio between the distance the pointer covered on the screen and the distance it covered inside the page. The privacy policy names all ten of those fields individually, because that record is the whole of what this site writes to your browser storage. Those are witnesses, and they exist because the interesting failures are not arithmetic. They are compared on every visit and on a timer rather than on an event, because a pixel-ratio change can fire no event whatsoever: in testing, the ratio walked from 1 to 3 and back with the viewport fixed and nothing at all was dispatched. Polling is not belt and braces here; it is the only mechanism that works.
Three details of the storage model matter enough to be written down.
- The bound applied to the stored figure is a panel bound, not an input bound. A human match is only plausible between 1.5 and 16 CSS pixels per millimetre, but that is a fact about matching, not about panels. The stored density is checked against 1.2 to 28 device pixels per millimetre — roughly 30 to 711 pixels per inch, a television at one end and headroom above today's densest phones at the other. Checking the reconstructed CSS figure instead would throw away a perfectly good calibration for the crime of being read back at a higher pixel ratio, which is the failure this whole design exists to avoid.
- A record that fails its schema or its bounds is discarded and said so. It is not silently replaced by the 96-pixel assumption, and it is not repaired. The record carries a schema version for the same reason: a changed shape must be unreadable rather than misreadable.
- A measurement that could not be taken is not a measurement of zero. Any witness the page could not obtain is stored and compared as absent, never coerced into a number, because a zero in that position reads as a violent disagreement with the display and would drop an honest calibration out of green for no reason.
After about six months without a re-check the readout leaves green of its own accord and asks for another twenty seconds. Nothing has gone wrong at that point; it is an admission that the tool has no way to know what has changed since.
Where those claims stop
This is the longer half, and the part worth reading. Everything here is a failure the tool either cannot see, cannot bound, or has decided not to paper over.
The monitor swap that nothing can detect
No ruler in a browser can detect a move to a different monitor of the same resolution. Take a 1080p profile from a 24-inch panel to a 32-inch one and every signal available to a web page is identical — same reported resolution, same pixel ratio, same window, same chrome, same measured CSS inch — while the glass is a third larger. The reading is then 33% wrong, in green, with a ±1.2% band printed beside it. This is the single largest error this site can produce, it is larger than every other term in the arithmetic combined, and there is no mechanism that could catch it: the browser is not concealing the panel's size, it does not have it. The only defence is the one written here and on every instrument — if you have moved to another screen, calibrate again even though nothing has asked you to. It is also the reason a calibration is re-offered after a long gap rather than treated as permanent.
Casting, mirroring and magnifiers
The same blind spot has three more shapes. A tab cast or mirrored to a television or projector is being rescaled by hardware that the page has no view of, and every reading is wrong by that scaling factor with no signal on the page. An operating-system magnifier — the accessibility zoom on macOS and Windows, as distinct from the browser's own page zoom — enlarges the composited output after the page has drawn it, so nothing in the page's own measurements moves. A browser profile synchronised to a second machine carries the stored record to a display it was never taken on. In each case the readout will look exactly as confident as it does when it is right. None of them is detectable, all of them are stated here rather than discovered, and each one is fixed by the same twenty seconds with a card.
Marks this ruler will not draw
A graduation is a claim that the distance between two marks is what the label says. On a raster display that claim requires the marks to survive as marks: one pixel of line and two pixels of clear gap, so three device pixels of pitch, centre to centre. Below that a comb of marks aliases into a flat grey band with nothing left to count, and drawing it anyway means printing a claim the screen cannot express.
| Graduation | Step | Device px per mm needed | Density needed | 24-inch 1080p (3.61) | 27-inch 1440p (4.28) |
|---|---|---|---|---|---|
| Millimetres | 1 mm | 3.0 | 76.2 ppi | yes | yes |
| Sixteenths of an inch | 1.5875 mm | 1.9 | 48.0 ppi | yes | yes |
| Thirty-seconds of an inch | 0.79375 mm | 3.8 | 96.0 ppi | no | yes |
| Half-millimetres | 0.5 mm | 6.0 | 152.4 ppi | no | no |
Read the last two columns rather than the first two. Half-millimetre marks cannot be honestly drawn on either of the two commonest desktop displays in the world, and thirty-second-inch marks cannot be drawn on the more common of the two. Every other on-screen ruler measured while this one was being built draws them at any density at all, and the difference between the two behaviours is completely invisible in a screenshot — which is precisely why it is written down here. When a level is dropped the page names the level and prints the density that would have kept it, rounding that density up to the next whole pixel per inch, because a screen sitting exactly on a threshold is not above it.
One object offered, fourteen carried and refused
Sixteen reference objects are carried in this site's data. One is offered as a primary reference: the ID-1 bank card. One more, a sheet of A4, is offered only as a second opinion. The other fourteen are refused by name when asked for.
The rule is that an object becomes selectable only once its dimensional tolerance has been read out of a published standard and recorded with its clause, its arithmetic, at least two independent sources and a date. That floor is applied by the engine at load rather than by an editor's judgement, so a row switched on without the evidence is demoted and refused with the missing item named — the table cannot be widened by editing a flag. The reason it is mechanical is that the failure mode is a single edit: a plausible-looking tolerance typed into a data file produces a band that computes correctly from a fabricated input and looks exactly like a measurement, and a tolerance guessed low understates the band, which is the one direction this site treats as a lie rather than an approximation. Banknotes, US Letter sheets and the coins are all in that position today: their nominal sizes are not in dispute and are published on the calibration page, and their tolerances are simply not known here yet, so they are not offered.
Two objects were verified and are withheld anyway, and they are the more interesting refusals. An older-style ID-2 card carries a better band than a bank card — about ±1.0% against ±1.2% — and is still not offered, because an ID-1 card and an ID-2 card are both "a card from my wallet". A user who picks the wrong row calibrates 22.7% wrong with every signal on the page identical: a green badge, a tight band, a plausible density, and no second reference to catch it. The mini-SIM card fails earlier still: its own band would be ±3.6%, and the object most people are actually holding is a nano-SIM, which is a different form factor entirely and 103% away. The principle underneath both is that a tolerance failure is bounded and an identification failure is not. A tolerance error moves the reading by the fraction of a percent the band already names. A mis-identification moves it by the ratio of two different objects, which no band covers and nothing on the page reveals — and a tight band printed over a 23% error is worse than no row at all.
A sheet of paper is offered only as a cross-check, and that is enforced rather than advised: ask the tool to calibrate from paper and it refuses and tells you to match a card first. Paper's length makes it an excellent second opinion, but a sheet bows away from a vertical screen, and unlike tolerance and hand slop that bias is systematic and sits outside the band arithmetic entirely. A band honest about what it models and silent about the largest thing it does not is not an honest band.
What the band does not model
The printed band bounds two things and only two things: the object's permitted dimensional spread, and 0.7 mm of alignment slop. It does not model a card that has been sat on and bowed, a card held at an angle to the glass rather than flat against it, the parallax between a thick cover glass and the pixels behind it, or the curvature of a curved panel. None of those are small in principle, and none of them are measurable from inside a web page. They are handled by choosing which objects are offered at all and by saying plainly that a bent card is a bad reference — never by inflating the number until it covers them, because a band inflated to cover the unmeasured stops meaning what it says.
Where the browser declines to say
Some of the arithmetic above depends on the browser reporting a change, and not all of them do. On WebKit — Safari on macOS and iOS — page zoom deliberately does not move the reported pixel ratio, which is a considered position rather than an oversight: the ratio is treated as a property of the hardware, not of the user's zoom. On that engine, zoom changes the physical size of a CSS pixel with no signal to divide back out, so a stored calibration is presented as possibly stale and re-offered rather than corrected. That is a worse experience and an honest one, and it is what the neutral staleness state exists for. Fingerprinting-resistance modes — Firefox's resist-fingerprinting, Tor's letterboxing, Brave's farbling — deliberately corrupt exactly the values this design reads; detecting them reliably is not possible, so the response is that a stored record failing its bounds is discarded and reported rather than quietly kept. And on macOS scaled resolutions the scaling factor lands in the reported pixel count instead of the pixel ratio, which makes the stored density a property of the framebuffer rather than of the panel; the pixel count is stored as a witness precisely so that case is caught as a change rather than absorbed as a correction.
One consequence of all this is a design decision worth stating: this site does not maintain a database of device screen sizes, and will not badge a density it inferred rather than measured. Such a table has to key on the reported resolution and pixel ratio, which iOS Display Zoom changes, which macOS scaled resolutions falsify, which Android collides across thousands of models, and which fingerprinting-resistance modes rewrite on purpose — producing a confidently wrong number under exactly the conditions where a user is least able to notice. The screen diagonal you can type in is accepted for one job only: moving the outline near where it belongs so there is less dragging. It is a seed and a sanity check, and it never earns a badge.
The cross-check gate is tighter than the bands
Matching a second, independent object and finding the two agree is the only evidence on this site strong enough to use the word verified in a readout. The gate is 1%: inside it, the state becomes cross-checked; outside it, the disagreement is reported as a number and the original calibration stands untouched. The tension is arithmetic and is printed rather than smoothed over — a card at ±1.2% and an A4 long edge at ±1.0% can legitimately differ by 2.1% with both readings correct and inside their own bands. So a disagreement above 1% means the second object did not confirm the first. It never means the first one was wrong, and no copy on this site will say that it does. The gate stays at a fixed 1% because a fixed threshold is one a reader can check, and a per-pair threshold is one a reader has to trust.
How the reference figures are kept
Each reference row carries its own verification date, its own source list, and the clause its tolerance was read out of together with the arithmetic that turned millimetres into a percentage. That last field is not decoration: it is what makes a derivation checkable without fetching the standard again, and writing it out is what caught a unit error in an earlier draft of the card's short-edge figure, where a difference in millimetres had been written into a percentage field and understated the band by a factor of 1.85.
When a row is re-read against its sources, that row's date moves and only that row's date moves — there is no blanket sentence anywhere on this site claiming that everything has been verified, because a blanket sentence cannot be checked and stops being true one row at a time. What this page can honestly tell you is what the data currently records, which is that the card and the A4 sheet carry dates and sources and the other fourteen objects do not. The calibration page prints every one of them, including the refusals and their reasons.