Two ratios do all the work
EM is relative and pt is absolute, so the conversion needs a fixed size to anchor against. That anchor is the computed font size of the parent element.
px = em × parent font size in pxEM means multiples of the inherited font size. Nothing else enters this line.pt = px × 0.75CSS fixes one inch at 96px and one point at a 72nd of an inch, so 72 divided by 96 gives the 0.75 factor.The 0.75 is not a rendering guess, it comes from the CSS specification, which pins the absolute units to each other at a fixed ratio. A 16px parent with font-size: 1.5em resolves to 24px, and 24px is 18pt in any browser on any screen. The number that varies between pages is the parent size, which is why this tool asks for it first.
The parent size is where most conversions go wrong
People type 16 into the base field out of habit. It is right only when the element inherits straight from an untouched root. Three common setups break that assumption.
- A resized root. Stylesheets that set
html{font-size: 62.5%}to make maths easier leave the root at 10px. Every EM below inherits from that unless something in between resets it. - A sized container. A card with
font-size: 0.875embecomes the parent for everything inside it. A heading at1.5emin that card measures 21px, not 24px. - Form controls. Inputs, selects and buttons carry a browser default that ignores the page font unless a rule sets
font: inherit. Their children measure against that default.
Reading the real number takes ten seconds. Open DevTools, select the parent element, and look at the Computed panel rather than the Styles panel. Computed shows the resolved pixel value after inheritance. That figure goes in the base field above.
EM compounds and pt does not
This is the practical difference between the two units, and the reason the nesting calculator sits inside the tool. Take a list where each level is styled at 0.9em.
By the fourth nesting the text has dropped below 8pt, which most print guidance treats as the floor for body copy. On screen the shrink is gradual enough to miss during review. Converted to a print stylesheet it becomes fixed, and a reader with tired eyes finds it immediately.
Once a value lands in pt it stops compounding. A child of an 18pt element that is itself set to 12pt renders at 12pt regardless of depth. That predictability is the whole argument for absolute units on paper, and it is also the argument against them on screen, where a reader who raises their default text size gets no change from a pt value.
Where points still belong
Point sizes have a narrow but real home in modern CSS.
- Print stylesheets. Inside
@media print, pt maps to the physical page the way designers, printers and word processors already measure. A brief asking for 11pt body copy is answered directly rather than converted in your head. - PDF generation. Headless Chrome, wkhtmltopdf and Prince all output a paged document. Sizes given in pt survive that pipeline without depending on a DPI setting somewhere in the chain.
- Matching an existing brand book. Print guidelines are written in points. Converting the whole document to px so a developer can convert it back is two chances to introduce a rounding error.
- Email templates. Older Outlook builds render through Word, which is far more comfortable with pt than with relative units.
Everywhere else, keep the screen rules in EM or REM. A typical setup keeps the whole stylesheet relative and overrides only the type scale inside the print block, which is exactly the handful of numbers this page produces.
Watch the rounding. A 16px parent gives clean numbers at 0.5em steps, because 16 divides evenly into the 0.75 factor. A 15px or 17px parent does not, so 1.3em on a 15px base lands at 14.625pt. Round to one decimal for a stylesheet. Printers resolve far finer than that, and a page full of three decimal values is harder to review than it is accurate.
What this conversion will not tell you
The arithmetic is exact. The result on paper is not, for reasons that sit outside any converter.
- Optical size varies by typeface. Two fonts at 11pt print at different apparent sizes, because x-height differs. Garamond at 11pt reads smaller than Verdana at 11pt. Proof on the actual face before locking the number.
- Browsers disagree about print scaling. Print dialogs apply their own scale factor, and the fit to page setting rescales everything. A pt value is stable in the stylesheet, not necessarily on the sheet that leaves the tray.
- Minimum font size settings still apply. A browser configured with a minimum size will lift small pt values on screen, so a print preview in that browser misreports the page.
- The 96px inch is a convention. It matches typical desktop displays and it is what CSS defines, but a device with a very different pixel density maps the same declaration to a different physical size on screen. On paper the mapping holds.
Everything on this page runs in your browser tab. No values are sent anywhere and nothing is stored between visits. If you need the reverse trip, Point to EM takes a print size back to a relative value against the base you pick.
