CSS Unit Converter

Convert between px, rem, em, pt, and percent with a base size.

This tool runs entirely in your browser. Your data is never uploaded, never stored, and never leaves your device.

Restates a single CSS length in px, rem, em, pt and percent side by side, so a value handed over in one unit can be written into a stylesheet in whichever unit that stylesheet uses.

How to use it

1Set Base font-size to the root font-size your site actually uses; 16 is the browser default and the value the tool starts on.
2Enter the value and choose the unit it is written in now.
3Read the four remaining units in the list below and copy the one you need.

Example

Input: Base 16 · value 24 · from px
Output: 1.5 rem · 1.5 em · 18 pt · 150 %

rem and em always print the same number here, because both are computed against the base you typed. In a real page only rem behaves that way — em resolves against the parent element's font size, so it diverges the moment you nest it inside something resized. Percent is likewise treated as a percentage of that base font size, not of a container's width. Figures are trimmed to four significant figures, so 17px reports as 1.063rem rather than the exact 1.0625.

What happens to your data

Every figure is arithmetic against the base font-size you typed in — the tool never inspects your own page, reads no computed style off the document root, and loads no stylesheet to sample. Points use the fixed CSS ratio of 96px to 72pt rather than anything about your screen's real DPI, so nothing is learned about your display, and no value you try is kept after you leave.

Last updated August 2026

A design file says 24px and the stylesheet you have to put it in is written entirely in rem. Or the other way round: an inherited print stylesheet is in pt, a component library ships em, and you need the same length restated in whichever unit the codebase already uses.

Settle the base font-size before you convert anything, because every result except the pt row hangs off it. The browser default is 16px and that is where the field starts, which is right for most sites. It is wrong for any site that resets the root — the old font-size: 62.5% trick makes 1rem equal 10px, and a page built that way needs 10 in the base field or the rem values you copy are computed against a root the page does not have.

The other thing worth knowing first is what no converter can restate. vw, vh, vmin, ch and ex have no fixed relationship to a pixel — they depend on the viewport or on the font that actually renders, so they change per device and per typeface. Per cent is the same trap in a smaller way: on width, padding or margin it refers to the containing block, not to any font size.

The common mistake is converting a whole stylesheet. Type, and the spacing around it, benefit from rem because they follow the reader's own text setting. A 1px hairline turned into 0.0625rem gains nothing and can land on a fraction of a device pixel.

How it works

Toolvore converts through pixels rather than between units directly. Whatever you type becomes a pixel figure first — rem and em multiply by the base, pt multiplies by the fixed CSS ratio of 96 to 72, per cent is your value divided by a hundred and multiplied by the base — and that pixel figure is divided back out into the four units you did not pick. The unit you selected is dropped from the list, so there are always four rows, and they recompute on every keystroke rather than behind a convert button. Two limits matter before you paste a result into a stylesheet. Every figure is trimmed to four significant figures and the Copy button hands over exactly that trimmed string, so 17px comes back as 1.063rem rather than the exact 1.0625rem. And what lands on your clipboard is a bare number with no unit attached, so the rem, px or pt still goes in by hand. A negative value is refused, and the base has to be a positive number.

Common use cases

Turning a designer's px spec into the rem a stylesheet already uses
Checking what 1.5rem works out to when the root font size is not 16
Converting pt sizes out of a print stylesheet into px for a screen preview
Working out the rem equivalent of a breakpoint written in px
Rewriting a legacy stylesheet's font sizes onto one consistent unit
Sanity-checking a percentage font-size against the px figure it produces

Frequently asked questions

Is 1rem always 16px?＋

No — 16px is only the usual default. rem resolves against the font-size on the html element, so a stylesheet declaring html { font-size: 20px } makes 1rem 20px throughout the document. The default itself is a browser setting the reader controls: someone who has raised their default text size to 20 gets larger rem lengths on every site, which is the reason to use the unit at all. Page zoom is separate, since it scales px and rem alike. Put whatever your root rule declares in the base field rather than what you assume it is.

What is the difference between rem and em?＋

Both are relative to a font size; they differ in whose. rem always looks at the root element, so 1.5rem is the same length wherever it sits in the tree. em looks at the element's own font size for most properties, and at the parent's when setting font-size itself, which makes it compound: a 0.9em list nested in a 0.9em list renders at 0.81 of the original. That compounding is what you want when padding should grow with a component's own text, and a nuisance when you expected a fixed value. Nesting depth decides which of the two bites you.

Should font sizes be in px or rem for accessibility?＋

It matters to one specific reader: the person who raised the default text size in their browser settings instead of using zoom. Type set in px ignores that setting entirely, while rem and em follow it. Zoom helps either way, but zoom enlarges the layout too, which is usually not what someone with mild low vision is after. Most teams settle on rem for type and anything that should grow alongside it, and px for things that should stay put, such as borders, one-pixel rules and the odd icon that blurs at a fractional size.

Is the html font-size 62.5% trick still worth using?＋

It was popular because the arithmetic becomes trivial: with 1rem at 10px, 2.4rem is plainly 24px. The cost is that you have replaced the reader's chosen default with a fraction of it, so anything you forget to give an explicit size to inherits 10px rather than their 16. In practice you end up restating a size on more elements than the trick ever saved you. If the only goal is avoiding division in your head, doing the division somewhere else is cheaper. Inherited a codebase that already does it? Put 10 in the base field.

How many pixels is 1pt in CSS?＋

One and a third, because CSS fixes the relationship at 96px to 72pt whatever your display actually does — so 12pt is 16px, 9pt is 12px and 24pt is 32px. That ratio is a definition rather than a measurement of your screen. It is also why a point size lifted from Word or InDesign does not land at the same physical size on a monitor as on paper: the print application means one seventy-second of a real inch, the browser one seventy-second of a notional inch 96 CSS pixels wide.

Can I convert vw, vh or ch to px?＋

Not into a number that stays true. 1vw is one per cent of the viewport width, so it is one length on a phone, another on a wide monitor, and different again the moment the window is dragged. 1ch is the width of the zero glyph in the font that is actually rendering and 1ex is its x-height, so both shift when the typeface changes or a webfont fails and a fallback takes over. Measure them on one device for a sanity check if you like, but the figure is not portable.

Should media query breakpoints be in px or em?＋

px is the common choice and it is defensible when readers rely on zoom. em breakpoints — which browsers resolve against the initial font size rather than your own html rule — also respond to a reader who has raised their default text size, so the layout drops to its narrower arrangement when the text grows and not only when the window shrinks. Whichever you choose, be consistent across the file: mixing the two leaves gaps and overlaps at the boundaries, because the two scales line up only at the default.

Is anything I type here sent anywhere?＋

No. The whole job is arithmetic on the three fields in front of you, and the base, the value and the unit live in the page's state until you close the tab. No request is made and no file is involved. Nothing inspects your own site either: it cannot read the font-size on your document root, does not fetch a stylesheet and does not sample your display's real DPI, which is precisely why the base has to be typed rather than detected. Copying goes through the browser's clipboard, and if the browser blocks that the button says so.