The first time a designer handed me a spec that said "body text 16px, headings 28px, small print 13px" and the front-end lead said "but we ship everything in rem," I did the division by hand in a calculator app. Sixteen over sixteen is one, twenty-eight over sixteen is one point seven five, thirteen over sixteen is zero point eight one two five. Then the base font size changed to ten pixels for a "62.5%" setup on a different project, and I did it all again. After the third time I built a small converter into the toolz.dev workflow, and it has quietly saved me from arithmetic mistakes on nearly every component I have styled since.
TL;DR: A CSS unit converter turns a value in one unit - px, rem, em, pt, or % - into the equivalent value in every other unit, based on a root font size you control (16px by default). To convert px to rem, divide the pixels by the root font size:
24px ÷ 16 = 1.5rem. To go the other way, multiply:1.5rem × 16 = 24px. The CSS Unit Converter does this instantly for every unit at once, runs entirely in your browser, and includes a px-to-rem reference table you can copy from.
This guide covers how the units relate, why the base font size matters so much, when to reach for each unit, and the exact math the converter runs. I have styled a lot of interfaces across WordPress themes, the WP Adminify admin UI, and React dashboards, and the unit question comes up in all of them. The rules are simple once you see the single number everything hangs on.
Why does px to rem conversion matter?
Pixels are the unit almost every design tool exports. Figma, Sketch, and Photoshop all think in pixels, so a handoff spec is a list of pixel values. Pixels are also easy to reason about because one CSS pixel is a fixed reference size that does not change when the user adjusts anything.
That fixedness is exactly the problem for accessible, responsive interfaces. When someone increases their browser's default font size - a setting many people with low vision rely on - text sized in fixed pixels ignores the change completely. Text sized in rem scales with it. The same is true of browser zoom on some older configurations and of user stylesheets. If you want your typography to respect the reader's preferences, you size it in a relative unit, and rem is the one that behaves predictably across a whole page.
So the common workflow is: design in pixels, ship in rem. That leaves you doing division all day, and division is where small errors creep in. Writing 0.8125rem instead of 0.875rem for a 13px value is the kind of typo that ships to production and makes one label look subtly wrong. A converter removes that risk, which is the whole reason I keep one in reach. If you work across a lot of these tasks, the broader web developer toolkit covers where unit conversion fits alongside the other everyday jobs.
What is the difference between px, rem, em, pt, and %?
Every one of these units resolves to a number of CSS pixels at render time, a relationship CSS Values and Units Level 4 pins down: the reference pixel is defined against a 96 dpi display, not against your screen. The difference is what they are measured against.
px is the CSS reference pixel. It is an absolute unit in the sense that it does not depend on any font size. 1px is 1px. This makes it predictable but also unresponsive to user preferences.
rem means "root em." One rem equals the font size of the root element - the html element. By default that is 16px, so 1rem is 16px, 1.5rem is 24px, and 0.5rem is 8px. Because it is always tied to the root, a rem value means the same thing everywhere in the document, no matter how deeply nested the element is.
em is relative to the font size of the current element. If an element's font size is 20px, then 1em inside it is 20px, 1.5em is 30px, and so on. The catch is that em compounds: if a parent sets font-size: 1.2em and a child also sets 1.2em, the child's effective size is 1.2 × 1.2 of the grandparent. This tool assumes an element sized at the base, so em and rem read the same - and you model a specific em context by setting the base font size to that element's size.
pt is the point, inherited from print typography. CSS defines one inch as 96 pixels and 72 points, so 1pt equals 96/72 ≈ 1.333px, and 1px equals 0.75pt. Points belong in print stylesheets; on screen they are just a fixed multiple of the reference pixel.
% for font size is a percentage of the parent (or, at the root, the base). 100% equals the reference size and 50% equals half of it. At a 16px base, 100% is 16px and 150% is 24px.
Here is how the common values line up at the default 16px root:
| px | rem | em | pt | % |
|---|---|---|---|---|
| 12 | 0.75 | 0.75 | 9 | 75 |
| 14 | 0.875 | 0.875 | 10.5 | 87.5 |
| 16 | 1 | 1 | 12 | 100 |
| 18 | 1.125 | 1.125 | 13.5 | 112.5 |
| 24 | 1.5 | 1.5 | 18 | 150 |
| 32 | 2 | 2 | 24 | 200 |
The CSS Unit Converter generates this whole table for any base you set, so you can eyeball an entire type scale at once.
How does the base font size change everything?
The base (root) font size is the pivot for every relative unit. Change it and every rem, em, and % conversion changes with it, while px and pt stay put.
The browser default is 16px, which is why 1rem is normally 16px. But you can set the root to anything. A popular pattern sets html { font-size: 62.5%; }, which makes the root 10px (62.5% of 16). Now 1rem is a clean 10px, and rem math becomes "move the decimal point": 1.6rem is 16px, 2.4rem is 24px, 0.8rem is 8px. Teams adopt this so the numbers in their stylesheets read almost like pixels while still scaling with user preferences.
To model that in the converter, set the base font size to 10 and read the rem column. A 24px value now shows as 2.4rem instead of 1.5rem. This is also how you reason about em in a component that sets its own font size: if a card sets font-size: 20px, then em values inside it are relative to 20, so set the base to 20 to see what 1.5em resolves to.
The mistake I see most often is forgetting which base a value was computed against. Someone converts 24px to 1.5rem assuming a 16px root, then drops it into a project running the 62.5% trick where the root is 10px - and 1.5rem there is 15px, not 24px. The unit is relative, so the number only means something once you know the base. Whenever I paste a rem value between projects, I check the root font size first.
How do you convert px to rem and rem to px by hand?
The math is one division and one multiplication.
px to rem: divide the pixel value by the root font size.
rem = px ÷ base
24px ÷ 16 = 1.5rem
13px ÷ 16 = 0.8125rem
10px ÷ 16 = 0.625rem
rem to px: multiply the rem value by the root font size.
px = rem × base
1.5rem × 16 = 24px
0.875rem × 16 = 14px
2rem × 16 = 32px
px to em uses the same formula as rem when the element sits at the base font size, so 24px ÷ 16 = 1.5em. The difference is conceptual, not arithmetic: em is measured against the current element, so if that element's size differs from the root, you use its size as the base.
px to pt: multiply by 0.75, because 1px = 0.75pt. So 16px × 0.75 = 12pt. Going the other way, pt × 1.333 = px.
px to %: divide by the base and multiply by 100. So 24px ÷ 16 × 100 = 150%.
None of this is hard, but doing it forty times while styling a component is where fatigue produces typos. That is precisely the kind of repetitive, error-prone task the developer productivity tools philosophy says to automate - offload the arithmetic so your attention stays on the design.
When should you use each unit?
There is no single correct unit; there is a right unit for each job.
Use rem for font sizes. This is the strongest recommendation in the list. Rem scales with the user's browser font-size preference, which is a real accessibility win, and because it is anchored to the root it does not compound unexpectedly. Most teams size all their type in rem.
Use rem or px for spacing, depending on your system. Many design systems express margin and padding in rem so that spacing scales with type. Others keep spacing in px for pixel-perfect layouts. Both are defensible; pick one and be consistent.
Use em for things that should scale with their own element. Padding on a button that should grow with the button's font size is a classic em use - set the padding in em and it tracks the text automatically. Icon sizing relative to adjacent text is another.
Use px for borders and fine details. A 1px border should usually stay 1px; you rarely want a hairline to scale with font size. Media query breakpoints are also often written in px, though some prefer em there for zoom behavior.
Use pt only in print stylesheets. If you are styling something for @media print, points are the native unit of print and worth using. On screen, prefer px or rem.
Use % for fluid widths and occasionally font sizes. Percentage is everywhere in layout (width: 50%), and as a font size it is sometimes used at the root for the 62.5% trick.
What are the common mistakes with CSS units?
The first is the base-mismatch problem already described: converting against the wrong root font size. Always know your root before trusting a rem number.
The second is over-precise rem values. Some conversions do not divide evenly - 15px at a 16px base is 0.9375rem, and 13px is 0.8125rem. Those long decimals are exact but ugly, and rounding them too hard (say to 0.94rem) shifts the rendered size by a fraction of a pixel. My rule: keep three or four decimals for rem, or choose base and size values that divide cleanly. The converter rounds sensibly and trims trailing zeros so 24px reads as 1.5rem rather than 1.5000rem.
The third is compounding em. Nesting elements that each set an em font size multiplies the effect, so a deeply nested item can end up far larger or smaller than intended. If you find em surprising, that compounding is almost always why - switch those to rem and the surprise disappears.
The fourth is assuming pt and px are interchangeable. They are not; 12pt is 16px, not 12px. Mixing them up in a stylesheet that spans screen and print is a subtle bug.
How does the toolz.dev converter handle the math?
Under the hood the converter uses one idea: express every unit as a number of pixels, then convert through pixels. Each unit has a fixed "pixels per unit" given the base font size - px is 1, rem and em are the base, pt is 96/72, and % is base/100. To convert, it multiplies the input by its unit's pixels-per-unit to get a pixel value, then divides by the target unit's pixels-per-unit. That single pass gives every unit at once, which is why you see px, rem, em, pt, and % update together as you type.
It also parses values with units attached, so pasting 24px fills in both the number and the unit for you. Results are rounded to a few decimal places and stripped of trailing zeros for readability, and each has a one-click copy button that copies the value with its unit suffix ready to paste into CSS. Everything runs client-side - nothing you type is uploaded - which matches the privacy-first approach behind every tool on the site.
If you are also picking colors or building shadows for the same component, the CSS Gradient Generator and Box Shadow Generator live one click away, and the broader unit converter handles physical units like length and weight when your work strays outside CSS.
Frequently asked questions
How do I convert px to rem?
Divide the pixel value by the root font size. At the browser default of 16px, rem = px ÷ 16, so 16px is 1rem, 24px is 1.5rem, and 8px is 0.5rem. Enter the pixel value in the converter and the rem equivalent appears instantly at whatever base font size you set.
How do I convert rem to px?
Multiply the rem value by the root font size. At a 16px base, px = rem × 16, so 1rem is 16px, 1.5rem is 24px, and 0.75rem is 12px. Change the base font size in the tool if your html element uses a different value.
What is the default root font size?
Browsers set the html element to 16px by default, which is why this converter starts at 16. Because 1rem always equals the root font size, that default makes 16px equal to exactly 1rem. Users can change their browser's default text size, which is one reason rem is preferred for accessible, scalable typography.
What is the difference between rem and em?
A rem is always relative to the root html font size, so it stays consistent across the whole page. An em is relative to the font size of the current element, so it can compound when nested elements each set their own size. Set the base font size in the tool to model a specific em context.
How do px and pt relate in CSS?
CSS defines one inch as 96 pixels and 72 points, so 1pt equals 96/72 ≈ 1.333px, and 1px equals 0.75pt. Points come from print typography; on screen they are a fixed multiple of the CSS reference pixel. Use px or rem for screen work and reserve pt for print stylesheets.
What does the 62.5% font-size trick do?
Setting the html font size to 62.5% makes the root font size 10px, so 1rem becomes a convenient 10px and rem math turns into moving the decimal - 1.6rem is 16px, 2.4rem is 24px. To model this in the converter, set the base font size to 10 and read the rem column.
Should I use px or rem for font sizes?
Rem is generally preferred for font sizes because it scales with the user's browser font-size preference, which improves accessibility, while fixed px does not. Many teams design in px and convert to rem for the final CSS. Layout details like borders often stay in px.
Why does the converted value have long decimals sometimes?
Some conversions are not exact - 15px at a 16px base is 0.9375rem, and pt values often produce repeating decimals. The tool rounds to a few decimal places and trims trailing zeros for readability. For pixel-perfect layouts, round rem values to two or three decimals or pick a base that divides your sizes cleanly.
