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 — are obviously not physical. The others look physical: in, cm, mm, pt, pc. They are not. The specification fixes them against the pixel by definition: one inch is exactly 96 pixels, and everything else follows from it. A millimetre is 96 ÷ 25.4 = 3.7795 pixels. A centimetre 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 millimetres of glass depends entirely on how many pixels your display puts in a millimetre, and the browser has not been told. It is not that the browser measures badly. It does not measure at all: the number was decided in a specification, and every browser honours the specification exactly.

The one place these units are genuinely physical is print. When a page goes to a printer, a millimetre in the stylesheet becomes a millimetre 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 is not small and it is not in a consistent direction, which is what makes it interesting. Below, the pixel 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 actually puts in a real inch — the panel's density divided by the pixel ratio. The last column is 96 divided by that: the physical length a CSS inch comes out as.

Read the ends of that range rather than the middle. An old 1080p desktop monitor is one of the few displays where a CSS inch is too long, by about 4.6%. A 15.6-inch 4K laptop running at 100% scaling draws the same CSS inch at roughly a third of an inch. Between them sit the machines most people are actually using, at 24% to 42% short. There is no correction factor that fixes all of these at once, because the error is a property of the individual panel and its scaling, not of the web.

And it is invisible. A ruler drawn at 96 pixels per inch looks precisely as finished as one drawn from a measurement — same ticks, same numbers, same confidence. Nothing about the picture tells you which one you are looking at, which is the entire reason this site prints a calibration state next to every reading and reserves green for the state where a real object has been matched.

"High-DPI screens fixed this" — they did not

The claim turns up often enough to be worth answering with arithmetic. 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 is a statement about how the specification is written. It is not a behaviour any shipping browser implements, because implementing it would require the display's physical size, and no browser has it.

Take the iPhone 15 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 — on one of the densest screens most people own. A high pixel ratio multiplies both sides of the fraction; it does not connect either side to the glass.

Why the browser cannot simply 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 millimetre. The resolution media query looks promising and is circular: it reports 96 × the pixel ratio, because 96 is the definition this whole page is about.

The remaining idea is a lookup table — key on the reported resolution and pixel ratio, return a known panel density. This site rejects it, on engineering grounds before posture. 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 instead of 430×932 and the table confidently identifies a different phone. iPad multitasking moves the viewport without moving the screen. External monitors are unknown to any table. And the browser modes that resist fingerprinting deliberately corrupt exactly the values such a table keys on — which is the other half of the objection, since a size database is fingerprinting-shaped in a browser whose whole job here is that nothing leaves the device.

Screen diagonal is the honest version of the same idea, and this site accepts it for one job only. 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 — but only if the reported pixel count really is the panel's native one, which is false under macOS scaled resolutions, false in Safari under page zoom, and false wherever the values are being rewritten on purpose. So a diagonal moves the outline to roughly the right place and is printed alongside a card match as a sanity check. It never earns the calibrated state on its own.

What actually fixes it, and what it costs

One object of known size, held against the glass. You drag an outline until its edges agree with the object's, and the page divides the matched width in pixels by the object's width in millimetres. That single ratio converts every subsequent reading, and it is the only number in the chain that came from the physical world. A bank card is the usual object because it is rigid, it is long enough that hand error is a small share of it, its size is fixed by ISO/IEC 7810 at 85.60 × 53.98 mm, and nearly everyone has one — the alternatives, and how far each is permitted to vary, are in their own guide.

It is not free, and the cost is a number rather than a shrug. The card's own permitted spread is 0.351% of its long edge, and lining two edges up by eye is taken here 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 instead spreads the same hand error over 53.98 mm and the printed band widens to ±1.7%, which is why the ruler asks you to stand the card upright on a phone rather than quietly dropping to the short edge.

A calibration is also worth keeping, and what gets stored matters. Storing pixels-per-millimetre in CSS pixels means the calibration dies the moment you change page zoom or display scaling, because both of those change what a CSS pixel is. So the stored quantity here is device pixels per millimetre, which a change in the pixel ratio divides back out of: page zoom moves that ratio on Chrome, Edge and Firefox, an operating-system display-scaling change moves it on Windows and on GNOME, and in those cases the calibration survives and the correction is reported rather than hidden. Where the ratio does not move, nothing is corrected and nothing pretends to be. WebKit deliberately does not move the pixel ratio on page zoom — it treats that value as hardware — and macOS scaled resolutions put the scaling factor in the reported pixel count rather than in the ratio, which is why that count is stored as a witness. In both cases the readout drops out of green into a neutral state that asks for a twenty-second re-check, instead of quietly correcting a number it cannot see.

What calibration still cannot tell you

Two limits are worth knowing because no tool on this SERP can escape them either.

A monitor swap is undetectable. Move the same browser profile from a 24-inch 1080p panel to a 32-inch one and every signal a page can read is identical — same resolution, same pixel ratio, same everything — while the physical size of a pixel has changed by a third. Nothing on this site can catch that, which is why a calibration is re-offered after about six months even when no signal has moved, and why the site says "re-checks itself when your display changes" rather than anything stronger. Casting, screen mirroring, operating-system magnifiers and the same profile carried to another machine are all in the same category.

Some marks cannot honestly be drawn at all. A tick needs about three device pixels of separation from its neighbour to read as a separate mark rather than as grey; below that a comb of ticks aliases into a band. Half-millimetre marks therefore need about 6.0 device pixels per millimetre, 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-millimetre graduations cannot be resolved — and this site drops the level and names it in the readout rather than drawing marks it cannot separate. A ruler that draws them anyway is not offering more precision; it is offering a picture of precision.

The figures on this page were checked on 2026-08-09. The seven-display table is arithmetic on published panel densities rather than a survey, and it is included because the derivation can be followed in the two middle columns rather than taken on trust.

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

Three questions, in order of how quickly they settle it. Does the page say what state it is in — assumed, or measured from something? Did it ever ask you for a physical object? And 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, and the table above says roughly how far out that puts it on your machine.

The check takes ten seconds on any of them, including this one: hold a card against the screen and see whether the ruler agrees that it is 85.60 mm. If it does not, the difference is the error you have been measuring with. On this ruler that step is the calibration rather than a test of it, and the method, the ISO clauses and every source are published on their own page.