मुफ़्त PX से REM कन्वर्टर
विन्यास योग्य बेस फ़ॉन्ट आकार के साथ पिक्सेल को rem में और इसके विपरीत कनवर्ट करें।
संदर्भ तालिका
| PX | REM |
|---|
यह कैसे काम करता है
REM का अर्थ "root em" है और यह रूट तत्व के फ़ॉन्ट आकार के सापेक्ष है। डिफ़ॉल्ट रूप से, ब्राउज़र 16 px का उपयोग करते हैं। सूत्र है: rem = px / base।
अक्सर पूछे जाने वाले प्रश्न
px के बजाय rem क्यों उपयोग करें?
REM इकाइयाँ उपयोगकर्ता की ब्राउज़र फ़ॉन्ट आकार सेटिंग के अनुकूल होती हैं, सुगम्यता में सुधार करती हैं।
em और rem में क्या अंतर है?
EM पैरेंट तत्व के फ़ॉन्ट आकार के सापेक्ष है और नेस्टेड तत्वों में संचित हो सकता है। REM हमेशा रूट फ़ॉन्ट आकार के सापेक्ष होता है।
कौन सा आधार उपयोग करें?
अधिकांश परियोजनाएँ 16 px का ब्राउज़र डिफ़ॉल्ट उपयोग करती हैं। कुछ डेवलपर्स html { font-size: 62.5% } सेट करते हैं।
What rem actually is
"Rem" stands for root em. The W3C CSS Values Level 3 spec defines it as "equal to the computed value of font-size on the root element", i.e., on the <html> element. Browsers default <html> to 16px unless overridden, so on a vanilla page 1rem = 16px, 0.5rem = 8px, 1.5rem = 24px, 2rem = 32px.
If a stylesheet declares html { font-size: 20px }, then 1rem = 20px for the rest of the document. If the user has bumped their browser default to 24px (a common low-vision adjustment), 1rem = 24px even with no stylesheet override, and that is the entire accessibility case for rem in one sentence.
Why rem matters: the accessibility case
Browsers expose two different scaling mechanisms to users, and they behave differently with respect to units:
- Browser zoom (Cmd/Ctrl + or pinch), uniformly scales the entire viewport. A 16px element at 200% zoom takes the same screen space as a 32px element at 100% zoom. Both
pxandremscale identically under zoom, so zoom on its own doesn't justify rem. - Browser default font-size preference: buried in browser settings (Firefox
about:preferences, Chrome's Customize fonts). When the user changes "Default font size" from 16 to 24 (very common for low-vision users), the<html>element starts computing at 24px. Everyremvalue automatically scales by 1.5×; every fixed-pxvalue stays exactly the same.
This is why a layout built in rem respects the user's accessibility preference and a layout built in px doesn't. WCAG 2.2 Success Criterion 1.4.4 (Resize Text, Level AA) requires that text can be enlarged to at least 200% without loss of content or functionality. Browser zoom alone passes this technically, but rem-based layouts pass it more cleanly because they respect the more granular default-font-size mechanism, which is what users with low vision actually adjust day-to-day.
The em compounding gotcha that motivates rem
Before rem, the only way to get scalable typography in CSS was em, which is relative to the parent element's font-size, not the root. The classic problem: nested elements with em-based font sizes compound.
.list { font-size: 1.2em; }
.list .list { font-size: 1.2em; } /* renders at 1.44× the grandparent */
.list .list .list { font-size: 1.2em; } /* now 1.728× */Three nested lists balloon to nearly twice the body size, which is almost never intended. rem solves this by anchoring to the root every time, three nested elements at 1.2rem are all 19.2px regardless of nesting depth. This is why most modern stylesheets use rem for font-size and reserve em for component-internal proportions (icon sizes that should match button text, padding inside a button that scales with its label).
The 62.5% trick, convenient math, debatable accessibility
A pattern popularised by Jonathan Snook in his May 2011 article: set html { font-size: 62.5% }. Because 62.5% × 16 = 10, this makes 1rem = 10px by default, convenient mental math. 1.6rem = 16px, 2.4rem = 24px, 4.8rem = 48px. Designers liked it because it removes the awkward "divide by 16" arithmetic from every value.
The accessibility critique (raised at the time and reinforced in later writing): setting the root font-size to 62.5% effectively shrinks whatever the user has chosen in their browser preferences. A user who set their default to 24px because they have low vision would see body text at 15px, defeating the whole point of using rem. The modern rebuttal is to set the root to 62.5% but explicitly declare body font-size at 1.6rem (back to 16px) so the user override still cascades properly. Many teams skip the trick entirely and live with the slightly less elegant math.
When to use rem, when to use px, Comeau's framing
Josh W. Comeau's article "px or rem?" (May 2022, updated May 2025) offers the most useful single-question heuristic for this decision. Ask: "Should this value scale up as the user increases their browser's default font size?" If yes, use rem. If no, use px.
By that test:
- Use rem for: font-size, vertical margins/padding (which are tied to type rhythm), button widths and other content-shaped containers, line-length max-widths, breakpoints (so layout shifts at the right zoomed-in size for low-vision users).
- Use px for: borders (a 1px hairline should stay a hairline), horizontal padding/decoration, shadow radii, image sizes when the image has a fixed pixel intent, fine icon dimensions.
The single-question test produces consistent answers across thousands of decisions in a codebase, which is the real win, the resulting style sheets behave the way users expect under both zoom and font-size customisation.
Tailwind CSS 4 went rem-everywhere
Tailwind CSS v4.0 (January 2025) shipped a fully rem-based default scale. Every typography token (text-xs 0.75rem through text-9xl 8rem) and every spacing token (p-1 0.25rem, p-4 1rem, m-8 2rem) is in rem out of the box. Tailwind 4 deliberately leaves the <html> root at the browser default of 16px (they explicitly do not apply the 62.5% trick) so the user's accessibility preferences cascade cleanly. Tens of millions of projects now ship rem-based design systems by default, which is the strongest argument that the ecosystem has converged.
Conversion table at the default 16px root
| Pixels | Rem | Common use |
|---|---|---|
| 8 px | 0.5 rem | Half the base unit, small spacing |
| 12 px | 0.75 rem | Caption / fine print |
| 14 px | 0.875 rem | Secondary text |
| 16 px | 1 rem | Body text default |
| 18 px | 1.125 rem | Slightly emphasised body |
| 20 px | 1.25 rem | Lead paragraph |
| 24 px | 1.5 rem | H4 heading; large UI text |
| 32 px | 2 rem | H3 heading |
| 48 px | 3 rem | H2 / hero heading |
| 64 px | 4 rem | H1 / display heading |
Where rem fits in the modern toolkit
Rem is the right default for type and type-anchored spacing, but it's not the answer to every layout problem. The modern toolbox also includes:
- clamp() for fluid typography,
font-size: clamp(1rem, 0.8rem + 1vw, 1.5rem)sets a rem floor and ceiling with a viewport-driven middle. CSS यूनिट कन्वर्टर - Viewport units (
vw,vh, and the newersvh/lvh/dvhfor mobile), for hero sections and full-bleed elements that should scale with the viewport rather than the type. - Container query units (
cqw,cqh), for component-driven design where the same component might appear at different widths.
For everything else (body text, headings, paddings, button widths, breakpoints) rem is the path of least resistance and the most accessible default.
More questions
What if my project uses a non-default base font size?
Change the Base font size field above to whatever your project's html { font-size: … } resolves to. The conversion math remains rem = px ÷ base regardless of base. If your codebase uses 18px, 32px becomes 1.78rem; at 10px (the 62.5% trick) it becomes 3.2rem. Be aware that overriding the root font-size has accessibility implications for users who customise their browser default, see the 62.5% trick discussion above.
Why doesn't 0.625rem render exactly to 10px?
It does, mathematically, at the default 16px root, 0.625 × 16 = 10. But browsers render to subpixel precision and may snap final values to whole device pixels, so a 0.625rem border can occasionally appear slightly different from a hardcoded 10px border depending on monitor DPR. For pixel-perfect 1-pixel hairlines, use 1px directly; for everything else, the rem-based value is fine.
Can I mix rem and px in the same stylesheet?
Yes, and you should. Use rem for things that should scale with the user's font-size preference (typography, vertical rhythm, breakpoints) and px for things that shouldn't (borders, icon details, decorative shadows). Comeau's "should this scale?" question is the practical filter; the answer maps cleanly to one unit or the other almost every time.
Do build tools convert px to rem automatically?
Yes, PostCSS plugins like postcss-pxtorem and postcss-rem-to-responsive-pixel can rewrite px values in your authored CSS to rem during the build step, with configurable thresholds (e.g., "convert anything ≥ 12px"). They're useful when migrating an existing px-heavy codebase. A live converter like this page is still useful for one-offs, design-spec lookups, and learning the math by hand.
Does anything get sent to a server?
No. The conversion is one division, pure JavaScript arithmetic running locally in your browser. Nothing about your input leaves the page; the tool works offline once it's loaded.