Why an online ruler is wrong: a CSS inch is not an inch

The definition that causes it

CSS has two families of length unit. The relative ones (em, rem, vh) make no claim to a physical size. The others look physical: in, cm, mm, pt, pc. The specification fixes them against the pixel by definition: one inch is exactly 96 pixels, and everything else follows from it. A millimeter is 96 ÷ 25.4 = 3.7795 pixels. A centimeter is 37.795. A point is 4/3 of a pixel.

So a page that draws a 100 mm bar asks for 377.95 pixels and gets them. Whether those 377.95 pixels cover 100 millimeters of glass depends on how many pixels your display puts in a millimeter, and nobody has told the browser. The browser measures nothing here. The number was decided in a specification, and every browser follows the specification exactly.

These units are physical in one place: print. When a page goes to a printer, a millimeter in the stylesheet becomes a millimeter of paper, because the print pipeline knows the physical size of the sheet. That is why this site uses CSS physical units for printing and never for anything drawn on a screen.

What that costs, on seven real displays

The error can be large, and it runs in both directions. In the table below, the panel density is the panel's own, the pixel ratio is what the browser reports, and the fourth column is how many CSS pixels the display puts in a real inch: the panel's density divided by the pixel ratio. The last column is 96 divided by that, which is the physical length a CSS inch comes out as.

At one end, an old 1080p desktop monitor is one of the few displays where a CSS inch is too long, by about 4.6%. At the other, a 15.6-inch 4K laptop running at 100% scaling draws the same CSS inch at roughly a third of an inch. The MacBook Pro, the 13.3-inch laptop, the iPhone 15 and the Pixel 7 come out 24% to 42% short. No single correction factor fixes all of these, because the error belongs to each panel and its scaling setting.

You cannot see the error. A ruler drawn at 96 pixels per inch has the same ticks and the same numbers as one drawn from a measurement, and nothing in the picture tells you which one you are looking at. So the ruler here shows green only after a real object has been matched.

High-DPI screens do not fix it

A common claim is that a CSS inch becomes a real inch on a high-density screen. It comes from a reading of the specification's own note about which unit is the anchor: on low-density screens the pixel is the fixed unit and the physical units are derived from it, and on high-density devices the specification describes the relationship the other way round. That note describes how the specification is written. No shipping browser behaves that way, because it would need the display's physical size, and no browser has it.

The iPhone 15 has one of the densest screens most people own, so take its row above. The pixel ratio is 3, so a CSS inch is 96 CSS pixels and therefore 288 device pixels. The panel puts about 460 device pixels in a physical inch. 288 ÷ 460 = 0.63, so the CSS inch renders about 37% short. A high pixel ratio multiplies both sides of the fraction, and neither side is tied to the size of the glass.

Why the browser cannot look the answer up

There is no web API that reports the physical size of a display. The Window Management API's screen objects carry a pixel ratio, a label, positions and a primary-display flag, and not one millimeter. The resolution media query looks promising, but it is circular: it reports 96 × the pixel ratio, and 96 is the same CSS definition.

That leaves a lookup table: take the reported resolution and pixel ratio and return a known panel density. This site rejects it, for engineering reasons first. Android is thousands of devices with colliding logical resolutions and bucketed densities. On iOS, Display Zoom and Larger Text change the logical resolution the browser reports, so a zoomed iPhone 15 Pro Max reports 375×812 where it would otherwise report 430×932, and the table identifies a different phone. iPad multitasking moves the viewport without moving the screen. External monitors are unknown to any table. Browser modes that resist fingerprinting change exactly the values such a table keys on, and they do it on purpose. The other reason is privacy: a size database works like a fingerprint, and on this site nothing leaves the device.

The screen’s advertised diagonal gives a rough starting scale. If you tell the ruler you have a 13.3-inch screen, it can multiply the reported resolution by the pixel ratio, take the hypotenuse and divide, and land within a percent or two. That works only when the reported pixel count is the panel's native one, which it is not under macOS scaled resolutions, in Safari under page zoom, or wherever the values are being rewritten on purpose. So a diagonal moves the outline to roughly the right place, and the ruler prints it alongside a card match as a sanity check. A diagonal alone never earns the calibrated state.

What fixes it, and what it costs

One object of known size supplies the missing ratio. The usual one is a bank card or another ID-1 card: clean, flat, undamaged and smooth-edged, held just above the display so that it never touches the glass. Look at it square-on and drag the outline on screen until its edges agree with the card's. Never press or slide the card on the glass. Any extra gap or tilt is outside the printed band. The page divides the matched width in pixels by the object's width in millimeters. A card works because it is long enough that hand error is a small share of it, and ISO/IEC 7810 fixes it at 85.60 × 53.98 mm. The other reference objects, and the tolerances recorded for them, have their own guide.

The calibration carries an error of its own, and the site prints it as a number. The card's own permitted spread is 0.351% of its long edge, and the site takes lining two edges up by eye as 0.7 mm, which is 0.818% of 85.60 mm. Added as bounds, that is the ±1.2% this site prints beside a long-edge match, about 1.2 mm in every 100. Matching the short edge spreads the same hand error over 53.98 mm, and the printed band widens to ±1.7%. That is why the ruler asks you to hold the card upright just above a phone display, and preselects the short edge only when the long edge does not fit either way up.

A calibration should also last, so what gets stored matters. A figure in CSS pixels per millimeter would be lost the moment you changed page zoom or display scaling, because both of those change what a CSS pixel is. So the site stores device pixels per millimeter, and a change in the pixel ratio divides back out of that figure. Page zoom moves the ratio on Chrome, Edge and Firefox, and an operating-system display-scaling change moves it on Windows and on GNOME. In those cases the calibration survives, and the readout reports the correction. Where the ratio does not move, nothing is corrected. WebKit does not move the pixel ratio on page zoom, because it treats that value as hardware, and macOS scaled resolutions put the scaling factor in the reported pixel count and leave the ratio alone, so the site stores that count as a witness. In both cases the readout drops out of green into a neutral state that asks for a twenty-second re-check.

What calibration still cannot tell you

Two limits apply to every on-screen ruler, this one included.

A monitor swap cannot be detected. Move the same browser profile from a 24-inch 1080p panel to a 32-inch one and every signal a page can read stays the same, from the resolution to the pixel ratio, while the physical size of a pixel has changed by a third. Nothing on this site can catch that. So a calibration is re-offered after about six months even when no signal has moved, and the site claims only that it re-checks when the display reports something new. Casting, screen mirroring, operating-system magnifiers and the same profile carried to another machine fall in the same category.

Some marks are too fine for the screen to draw. A tick needs about three device pixels of separation from its neighbor to read as a separate mark; closer than that, a comb of ticks aliases into a gray band. Half-millimeter marks therefore need about 6.0 device pixels per millimeter, which is about 152 pixels per inch. A 24-inch 1080p monitor has 3.6 and a 27-inch 1440p has 4.3, so on the two commonest desktop displays half-millimeter graduations cannot be resolved. On those screens this site drops that level and names it in the readout, because marks the screen cannot separate add no precision.

The figures on this page were checked on 2026-08-09. The seven-display table is arithmetic on published panel densities, with no screens measured for it, and its two middle columns show each step of the derivation.

How to tell whether the ruler in front of you is calibrated

Three questions settle it, listed here quickest first. Does the page say what state it is in: assumed, or measured from something? Did it ever ask you for a physical object? Does it put a number on how wrong it might be? A ruler that answers no to all three is drawing 96 pixels to the inch. The table above shows how far out that puts it on seven example displays.

On this ruler, the safe check is the calibration: visually align a clean, smooth-edged card just above the display without touching it and see whether the readout identifies the 85.60 mm edge and its band. Do not press or slide it on the glass. Keep hard or abrasive objects away from the display and use the printable ruler or another physical ruler for them. The method, the ISO clauses and every source are published on their own page.