Typography Unit Converter

How to Convert a Typography Unit

Features

One Pixel, Twelve Different Names

Type a font size into a design tool, a print layout, and a stylesheet on the same day, and you'll hand-type three completely different-looking numbers for what might be the exact same visual size — a Figma frame in px, a print brief in pt or pica, a component library in rem. Typography units split into two families that behave nothing alike: absolute units like px, pt, pc, in, cm and mm never change no matter what surrounds them, while relative units like em, rem, %, ch and ex are always measured against something else — the root font size, the parent font size, or the current font's own metrics. Mix the two families without understanding which is which, and a design that looked correct in isolation can render at a subtly wrong size the moment it's dropped into a real page with its own font-size cascade already in motion. This tool converts across all twelve at once from a single input, and goes a step further than a typical lookup table by simulating the one behavior that catches even experienced developers off guard: how em values compound when they're nested. The point itself is older than any of this digital tooling — a French clergyman named Sébastien Truchet first proposed a rational typographic point in the early 1700s, the punch-cutter Pierre-Simon Fournier refined it into a 72-points-to-the-inch scale in 1737, and François-Ambroise Didot standardised it further in 1783, a lineage that eventually split into separate French and Anglo-American versions of “a point” that never quite agreed on the exact same length.

The DPI Myth That Refuses to Die

A surprising number of typography converters ask for your screen's DPI before converting px to pt, which sounds reasonable and is actually based on a misunderstanding. CSS defines the pixel as a fixed reference unit equal to exactly 1/96 of an inch, and the point as a fixed 1/72 of an inch — both are anchored to a physical inch by specification, not to how many real pixels your specific monitor packs into that inch. That's why 1pt equals exactly 1.333px in every browser, on every screen, at every resolution, whether it's a budget laptop panel or a high-density retina display: the operating system and browser handle real physical scaling separately, entirely underneath this fixed ratio, and it never leaks into the conversion itself. This is also exactly why the tool doesn't ask for your screen's DPI at all — doing so wouldn't make the number more accurate, it would just be asking for information the conversion never actually needed in the first place. The exact 1/72-inch definition is itself a relatively recent convenience: the traditional Anglo-American printer's point that typesetters used for most of the 20th century was officially 0.013837 inch — roughly 1/72.27 of an inch, not a clean 1/72 — until Adobe's PostScript system rounded it to an exact 1/72 inch in the 1980s specifically because that matched the 72-dpi resolution of the original Macintosh screen. CSS inherited that same rounded PostScript definition, which is part of why a pt value measured on an old metal-type specimen sheet won't translate to a pixel-perfect match on a modern screen.

A Developer, a Print Designer, and Someone Debugging a Word Export

A front-end developer handed a Figma file full of px values needs rem equivalents for a component library that respects a user's browser accessibility settings, and getting that translation wrong across dozens of components is a slow, error-prone way to spend an afternoon compared to converting each value once and moving on. A print designer adapting a magazine layout built in picas and points for a companion web page needs to know that a single pica becomes a clean 16px on screen, without doing the 12-points-per-pica arithmetic by hand for every heading and caption size in the brief. And someone debugging why text pasted out of a generated Word document renders at an unexpected size in a web-preview tool eventually lands on twips — the twentieth-of-a-point unit RTF and Office Open XML documents actually store font sizes in — and needs a fast way to turn that number back into something a browser understands. Font size is only half the layout question, of course; actual physical spacing still comes down to length, which the Length Converter handles directly for anyone converting a print bleed or margin measurement alongside the type itself. A design-system maintainer auditing an inherited codebase for accessibility runs into a quieter version of the same problem: a scatter of hard-coded px font sizes that never respond to a user's browser zoom or font preference, each one needing a clean rem conversion before an accessibility audit will pass, ideally checked against the project's actual root font size rather than an assumed 16px default.

Built to Catch the Compounding Problem Before Production Does

Most typography converters stop at a flat lookup table, which is genuinely useful but misses the behavior that causes the most real-world confusion: em doesn't just scale against one font size, it scales against whatever its immediate parent happens to be, and that parent was very possibly scaled against its own parent too. Set font-size: 0.9em on a reusable component, nest that component inside another element that also uses 0.9em, and the effective result compounds to roughly 81% of the base size rather than 90% — a gap that grows fast with every additional level and rarely shows up until a component gets reused somewhere its author never tested. The Em Compounding Simulator above walks through exactly that scenario, level by level, so the multiplication is visible instead of theoretical, right next to the explanation of why rem was introduced specifically to sidestep the problem by always resolving against the root element instead of a chain of nested parents. A root and parent font-size setting sit alongside the main converter too, so rem and em results reflect a real project's actual base size rather than assuming everyone uses the common 16px browser default.

Choosing the Right Unit for the Job

Reaching for px out of habit is the single most common typography mistake in a modern stylesheet, since it's rarely the unit that actually serves the situation best. Font sizes on the web generally belong in rem, specifically because it's the one unit that keeps working correctly when a visitor adjusts their browser's default text size for readability — a real accessibility need, not an edge case. Padding, margin, and letter-spacing tied to a specific piece of text often belong in em instead, precisely because compounding is a feature there: a button's internal padding growing along with its own label text is usually the intended behaviour, not a bug to avoid. Absolute units — pt, pc, in, cm, and mm — belong to print output almost exclusively; reaching for them in a web stylesheet is a strong signal that a value was copied from a print brief without being converted first. And ch, despite looking like a natural fit for anything measured in characters, is worth reaching for only when an approximate width is genuinely good enough, such as a search box sized to roughly fit its placeholder text, rather than anywhere a precise pixel width actually matters.

What This Converter Can't Decide for You

A few of these units resist a perfectly exact conversion by nature, and it's worth being upfront about where that happens rather than presenting false precision. Ch and ex are genuine font-metric measurements — the width of a “0” character and a font's x-height respectively — and they vary from typeface to typeface; this tool uses the common half-of-font-size approximation, which holds up reasonably well for many text fonts but shifts for a condensed or display typeface. A browser user who has raised their default font size for accessibility will see every rem-based size on a well-built page scale up accordingly, which is a feature rather than a bug, but it does mean a rem-to-px conversion calculated here reflects one specific base size rather than every visitor's actual rendered result. And print output ultimately depends on the specific printer, paper, and PDF renderer involved, so a pt or pica value converted here is a strong starting figure for a print layout rather than a guarantee of the final physical measurement once it leaves a specific print shop's equipment. None of that makes the underlying math any less exact — px, pt, pc, in, cm and mm convert between each other with zero rounding loss, since they're all fixed multiples of the same physical inch — it just means the handful of units that were always defined in terms of a specific font or a specific rendering environment carry that same real-world variability into any tool that converts them, this one included.