ColorKitFree rem to px calculator
REM to PX at every root that matters
Free and account-free: put in a rem value, say how your stylesheet sets the root, and the pixel size appears immediately — 1.5rem against the default 16px root is 24px. Below it, the same value is worked out again for each of the five font sizes a browser lets a reader choose, whose default text measures 9, 12, 16, 20 and 24 pixels. Switch the root from a percentage to an absolute pixel value and that column flattens to a single repeated number, which is what an accessibility audit is objecting to when it flags a pixel root.
- 100% free
- No signup
- 5 reader settings
- 62.5% preset
- Percent or px root
24px
root resolves to 16px
What 1.5rem renders at for each reader
| Browser setting | Default text | Your root | Rendered |
|---|---|---|---|
| Very small | 9px | 9px | 13.5px |
| Small | 12px | 12px | 18px |
| Medium (default) | 16px | 16px | 24px |
| Large | 20px | 20px | 30px |
| Very large | 24px | 24px | 36px |
A percentage root inherits the reader's choice, so the rendered column spans 13.5px to 36px across the five settings.
Values you meet in devtools
| rem | px |
|---|---|
| 0.625rem | 10px |
| 0.75rem | 12px |
| 0.875rem | 14px |
| 1rem | 16px |
| 1.125rem | 18px |
| 1.25rem | 20px |
| 1.5rem | 24px |
| 1.75rem | 28px |
| 2rem | 32px |
| 2.5rem | 40px |
| 3rem | 48px |
| 4rem | 64px |
Press Ctrl+V anywhere on the page to drop in a rem value straight out of the computed styles panel — no need to click the field first.
How to convert rem to px
Three steps from a computed value in devtools to the size a reader actually sees.
Drop in the value from the computed panel
Type or paste the rem figure — the stepper moves in 0.0625, which is one pixel at the default root, so nudging it walks whole pixels rather than arbitrary fractions. Pasting works from anywhere on the page and a trailing unit is stripped, so 1.375rem copied straight out of devtools goes in as it stands.
Describe your root rule honestly
Pick whether your stylesheet sets the root as a percentage of the reader's default or as an absolute pixel value, and enter the number you actually wrote. The two look identical at default settings and diverge for everybody else, which is precisely the thing this page exists to show. There is a one-click button for the 62.5% case because so many codebases use it.
Read the reader column, not just the headline
The five rows underneath run the same multiplication against the default text size each browser font setting produces: 9, 12, 16, 20 and 24 pixels. In percentage mode the rendered column spreads out across those five; in absolute mode it collapses to one repeated number, and that collapse is the accessibility bug rendered as a table.
Technical specifications
| Conversion | px = rem × the computed font-size of the html element; the html element, never body |
|---|---|
| Root modes | A percentage of the reader's default, or an absolute pixel value — the two agree at default settings and part company everywhere else |
| Reader settings modelled | Chrome's five steps, whose default text measures 9, 12, 16, 20 and 24px; Firefox replaces them with a free slider from 9 to 72px |
| 62.5% preset | One button: 1rem becomes 10px for a reader on Medium and 12.5px for one on Large |
| Media queries | rem inside @media resolves against the initial 16px and ignores your html rule, so the root field here does not describe breakpoints |
| Precision | Pixels to 2 decimal places; font-size keeps its fraction, and getComputedStyle reports values such as 13.44px rather than rounding to 13 |
| Devtools reference | 12 rem values from 0.625 to 4 — the ones that actually turn up in a computed styles panel |
| Offline | A static page with no network calls after load; the calculator keeps working with the connection off |
Frequently asked questions
What is 1.5rem in px?
It is 24px at the 16px root browsers ship with. Multiply the rem figure by whatever font-size the html element computes to, and 1rem is 16px, 1.25rem is 20px and 2rem is 32px on an untouched site. Declare a different root and the whole ladder moves with it, which is what the root control above is for.
Why does the computed panel show a size nobody wrote?
Because something above the element declared it. Devtools reports the value after the cascade, inheritance and the browser's own stylesheet have all had a turn, and that last one is easy to forget: an h1 with no rule of its own resolves to 2em of its parent. Numbers such as 15.4px that appear nowhere in your source almost always come from a chain of relative units, and the em to px calculator walks that multiplication level by level.
Does html { font-size: 62.5% } break accessibility?
No, because a percentage root still inherits whatever the reader chose — that is the entire reason it is written as a percentage rather than as 10px. Pinning the root with an absolute pixel value is the version that throws their setting away. The genuine cost of 62.5% is smaller and different: anything with no font-size of its own drops to 10px until you restore a 1.6rem rule on body, and forgetting that rule is how the trick earned its reputation.
Why is my 40rem breakpoint firing at 640px when 1rem is 10px on my site?
Because relative units inside a media query resolve against the initial font size, never against your html rule. The query is evaluated outside the document's own cascade, so 40rem is 40 × 16px = 640px whatever :root declares, and em behaves identically there. It is a deliberate design — a breakpoint that shifted whenever a component changed the root would be impossible to reason about — but it does mean the root field on this page has no bearing on media queries.
A reader set their browser font size to Large. What happens to my layout?
Their root becomes 20px, so everything sized in rem grows by a quarter while everything you wrote in pixels stays put. That mixture is what breaks: text 25% larger inside a 320px fixed-width card overflows it, and a 44px button whose label is 1.25rem loses its vertical centring. Checking the top and bottom rows of the table before shipping is cheaper than reading it in a bug report.
Does rem mean the same thing inside an iframe or a shadow root?
Inside an iframe no, inside a shadow root yes. An iframe is a separate document with its own html element, so rem there answers to the frame's root font-size and ignores the page hosting it. A shadow root is not a document and :host is an ordinary element in the outer tree, so rem inside a web component still resolves against the outer page's html — which is how a component sized in rem silently shrinks when it is dropped into a site using the 62.5% trick.
About rem, the root and the reader
Readers have two controls over text size and they do different jobs. Page zoom multiplies everything — pixels, images, borders, the lot — and a stylesheet cannot escape it. The default-font-size setting is narrower: it changes the initial value of font-size, which is to say it moves the root and therefore moves anything measured against the root. Chrome offers five steps whose default text lands at 9, 12, 16, 20 and 24 pixels; Firefox exposes a slider instead. A page built entirely in rem responds to both controls. A page built in pixels responds only to zoom, which is the coarser instrument and the one people give up on because it reflows the layout as well as the prose.
That distinction is why 62.5% keeps turning up in real codebases and why it keeps being misdiagnosed. Written as a percentage it passes the reader's choice straight through and merely rescales the arithmetic so that 1.6rem reads as 16px; written as 10px it does the opposite and hard-codes the root. If you are producing those values rather than reading them, the px to rem direction has the divisor presets for both conventions. And whatever the root ends up as, a unitless line-height survives the change untouched, because a factor is recomputed at each element while a length is inherited frozen.
The common failure in other rem calculators is answering with one number. One number assumes the reader is on the default, which is the only case where the question is trivial, and it quietly implies the root applies everywhere — including to media queries, where it does not. Two smaller places worth knowing: a value copied out of a computed panel has already been through inheritance, so it may not correspond to any declaration you can search for; and tracking scales differently from type, which is why letter-spacing is set in em rather than rem. If breakpoints are what brought you here, the media query generator writes the range syntax in either unit.
Where this calculator runs
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.