ColorKitFree px to rem converter
PX to REM, one value or the whole block
This px to rem converter is free and needs no signup: enter a pixel value and the root font-size your stylesheet declares, and the rem appears to four decimal places — 24px at the standard 16px root is 1.5rem. Because 16 is a power of two, every whole pixel divides into an exact rem at that root, so those four places are the answer rather than a rounding of it. Paste a declaration block into the second panel and every px token in it is rewritten at once, with 1px and 2px borders left alone unless you say otherwise.
- 100% free
- No signup
- Any root size
- Whole blocks at once
- 22-row reference
1.5rem
Exact: 1.5 × 16 returns 24 with nothing left over.
font-size: 1.5rem;Reference at a 16px root
| px | rem |
|---|---|
| 1px | 0.0625rem |
| 2px | 0.125rem |
| 4px | 0.25rem |
| 8px | 0.5rem |
| 10px | 0.625rem |
| 12px | 0.75rem |
| 13px | 0.8125rem |
| 14px | 0.875rem |
| 15px | 0.9375rem |
| 16px | 1rem |
| 18px | 1.125rem |
| 20px | 1.25rem |
| 24px | 1.5rem |
| 28px | 1.75rem |
| 32px | 2rem |
| 36px | 2.25rem |
| 40px | 2.5rem |
| 48px | 3rem |
| 56px | 3.5rem |
| 64px | 4rem |
| 80px | 5rem |
| 96px | 6rem |
Rewrite a declaration block
5 values rewritten, 1 left as px · 123 of 20000 characters used
Press Ctrl+V anywhere on the page to drop in a px value or a block of CSS — no need to click the field first.
How to convert px to rem
Three steps from a design handed over in pixels to a stylesheet written in rem.
Set the root before you touch the value
Find what your html or :root rule declares and put that number in the root field. The presets cover the 16px browsers ship, the 62.5% trick that makes 1rem equal 10px, and the 14, 18 and 20px roots design systems choose deliberately. This is the only way the arithmetic on this page can be wrong, and it fails silently: a stylesheet divided by 16 that ships against a 10px root renders at 62.5% of the size it was drawn at.
Convert the value you came for
Type the pixel figure and read the rem underneath, then take the ready-made declaration with the copy button. The line below the result says whether the division came out with nothing left over or was rounded to four places, and by how many pixels, so an exact 0.8125rem is distinguishable at a glance from an approximation.
Then feed the whole block through
Paste the rule set into the CSS-in box and every px token is replaced in a single pass, with a count of what changed and what was skipped. Zero collapses to a bare 0, negative and decimal values are handled, and the hairline checkbox keeps 1px and 2px in place so borders stay crisp. Copy the result back over the original and diff it.
Technical specifications
| Conversion | rem = px ÷ root font-size, with the root editable from 1px upward and presets at 16, 10, 14, 18 and 20px |
|---|---|
| Output precision | 4 decimal places; at a 16px root every whole pixel is exact there, because 1 ÷ 16 is 0.0625 and terminates |
| Worst-case rounding | 0.00005rem, which is 0.0008px at a 16px root — under the 1/64px (0.015625px) unit Blink lays out in |
| Batch rewrite | Up to 20,000 characters per pass; every <number>px token is replaced, comments and url() included, and 0px collapses to a bare 0 |
| Hairline guard | Values of 2px and under are left untouched while the checkbox is ticked, and the counter reports how many were skipped |
| Reference table | 22 rows from 1px to 96px, recomputed live against whatever root you set |
| Pasted CSS | Rewritten by a regular expression running in this tab; the block is never uploaded and nothing is written to storage |
Frequently asked questions
What is 16px in rem?
It is 1rem on any site that has not changed the root font-size. The conversion is a division — rem equals px divided by the computed font-size of the html element — and every browser ships that at 16px until the reader says otherwise. So 8px is 0.5rem, 24px is 1.5rem and 13px is 0.8125rem. If your own rule declares something other than 16px, none of those hold and the root field is the first thing to correct.
Should padding and margin move to rem as well, or only font-size?
Font-size is the one that matters and spacing is a preference. A font-size in px overrides what the reader asked their browser for, and that is the defect worth fixing; spacing in rem simply makes the whole layout breathe when they scale up, which some teams want and others find wastes room on wide screens. A common middle position is rem for type, px for structural gaps under 8px, and a rem spacing scale above that.
Will switching a stylesheet from px to rem change how the page looks?
Not at default settings, as long as you divide by the root you actually declared. The two rule sets compute to the same pixel values, so a reader who never touched their font size sees an identical render. What changes is the behavior of everyone who did touch it — and the real hazard during a migration is a half-converted file where some values were divided by 16 and the rest by 10.
What should happen to 1px borders and hairlines?
Leave them in px, which is why the hairline checkbox starts ticked. A 1px border written as 0.0625rem stops being one device pixel the moment a reader scales up, and a scaled hairline is rendered as a soft 1.25px smear instead of a crisp rule. The same reasoning covers box-shadow spread, focus-ring offsets and the sub-pixel dividers used on retina screens.
How many decimal places do I need to keep?
Four, and nothing is gained by carrying more. One sixteenth is 0.0625 exactly, so at the standard root every whole pixel terminates within four places with no remainder. At an unusual root the division can repeat — 15px over a 14px root is 1.0714285…rem — and rounding there leaves you at most 0.00005rem out, which is 0.0007px, well below the 1/64px unit Blink lays out in.
Is there a case for leaving a font-size in px?
Yes, three of them. Icon fonts and glyph sprites are drawn to a pixel grid and go soft when scaled off it; print stylesheets are better served by pt, where the unit means something physical; and fixed-height chrome — a 32px toolbar with 12px labels — breaks its own layout when the labels grow and the bar does not. Everything that is body copy, headings, form labels or button text should scale.
About pixels, rem and the root font-size
CSS Values 3 defines rem as the font-size of the root element — the html element, not body, which is the mistake that produces confidently wrong numbers. The unit exists because its older sibling does not stay put: em is measured against the parent, so two nested declarations multiply, and a chain of them drifts somewhere nobody intended. Rem answers to exactly one element on the page, which makes it boring, and boring is the whole feature. The reason to migrate away from pixels is narrower than it is usually stated: a declared px font-size cannot be moved by the default-font-size control in the browser's settings, so a reader who set theirs larger gets nothing from your stylesheet.
Two things trip up a conversion. The first is the divisor: a body { font-size: 14px } rule does not change what rem means anywhere, because body is not the root, and a codebase that half-believes it will end up with two divisors in one file. The second is deciding what should not be converted at all — hairlines, icon glyph sizes, the physical dimensions in a print stylesheet. Converting those buys nothing and costs sharpness. When you want to go the other way and find out what a rem value renders as for a reader who changed their settings, the rem to px page models all five of them, and the seven-unit converter covers pt and the absolute-size keywords that neither of those two touch.
Where converters generally fall short is in treating this as arithmetic on one number. A real migration is a file, not a value, which is why the rewrite panel exists and why it counts what it skipped as well as what it changed. It is also worth asking whether the px values deserve to survive the trip: a ramp of 13, 15, 17 and 22px accumulated over three years is better replaced by a generated modular scale than faithfully divided by 16, in the same way that a set of hand-picked brand tints is better replaced by an even ramp. A token file is the moment to fix the values, not to preserve them in a new unit.
Where the CSS you paste goes
Every number on this page is worked out by JavaScript running in the tab you are reading it in. Nothing you type, paste or open is uploaded, logged or kept, which is also why the tools carry on working after you disconnect from the network.
The rewrite panel is a regular expression, not a service. Your declaration block is transformed in the tab and then forgotten — it is not held in local storage, so closing the page loses it. Keep the original until you have diffed the output.