मुफ़्त 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% } सेट करते हैं।
rem वास्तव में क्या है
«Rem» root em के लिए stands करता है। W3C CSS Values Level 3 spec इसे define करता है «equal to the computed value of font-size on the root element», यानी <html> element पर। Browsers <html> को default 16px करते हैं जब तक overridden न हो, इसलिए vanilla page पर 1rem = 16px, 0.5rem = 8px, 1.5rem = 24px, 2rem = 32px।
यदि stylesheet html { font-size: 20px } declare करती है, तो document के बाकी हिस्से के लिए 1rem = 20px। यदि user ने browser default को 24px तक bump किया है (low-vision users के लिए common adjustment), 1rem = 24px किसी stylesheet override के बिना भी, और यही एक sentence में rem का पूरा accessibility case है।
rem क्यों matter करता है: accessibility case
Browsers users को दो different scaling mechanisms expose करते हैं, और वे units के respect में differently behave करते हैं:
- Browser zoom (Cmd/Ctrl + या pinch), पूरे viewport को uniformly scale करता है। 200% zoom पर 16px element उतना ही screen space लेता है जितना 100% zoom पर 32px element।
pxऔरremदोनों zoom के under identically scale करते हैं, इसलिए अकेले zoom rem justify नहीं करता। - Browser default font-size preference: browser settings में buried (Firefox
about:preferences, Chrome का Customize fonts)। जब user «Default font size» 16 से 24 में बदलता है (low-vision users के लिए बहुत common),<html>element 24px पर computing शुरू करता है। हरremvalue automatically 1.5× scale होती है; हर fixed-pxvalue exactly same रहती है।
यही कारण है कि rem में बना layout user की accessibility preference respect करता है और px में बना layout नहीं। WCAG 2.2 Success Criterion 1.4.4 (Resize Text, Level AA) require करता है कि text को कम से कम 200% तक enlarge किया जा सके बिना content या functionality के loss के। Browser zoom अकेले technically यह pass करता है, लेकिन rem-based layouts इसे अधिक cleanly pass करते हैं क्योंकि वे अधिक granular default-font-size mechanism respect करते हैं, जो low vision वाले users actually day-to-day adjust करते हैं।
em compounding gotcha जो rem को motivate करता है
rem से पहले, CSS में scalable typography पाने का एकमात्र तरीका em था, जो root की नहीं बल्कि parent element के font-size के relative है। Classic problem: em-based font sizes वाले nested elements 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× */तीन nested lists nearly body size के double तक balloon होती हैं, जो almost never intended होता है। rem इसे हर बार root से anchor करके solve करता है, 1.2rem पर तीन nested elements nesting depth regardless सब 19.2px हैं। इसीलिए अधिकांश modern stylesheets rem के लिए font-size use करती हैं और em को component-internal proportions के लिए reserve करती हैं (icon sizes जो button text match करनी चाहिए, button के अंदर padding जो label के साथ scale हो)।
62.5% trick, convenient math, debatable accessibility
Jonathan Snook के May 2011 article में popularised pattern: html { font-size: 62.5% } set करें। क्योंकि 62.5% × 16 = 10, यह default में 1rem = 10px बनाता है, convenient mental math। 1.6rem = 16px, 2.4rem = 24px, 4.8rem = 48px। Designers को यह पसंद था क्योंकि यह हर value से awkward «divide by 16» arithmetic हटा देता है।
Accessibility critique (उस समय raised और बाद की writing में reinforced): root font-size को 62.5% set करने से जो भी user ने browser preferences में choose किया है वह effectively shrink हो जाता है। एक user जिसने low vision के कारण default 24px set किया था body text को 15px पर देखेगा, rem use करने का पूरा point defeating। Modern rebuttal यह है कि root को 62.5% set करें लेकिन explicitly 1.6rem पर body font-size declare करें (back to 16px) ताकि user override properly cascade करे। कई teams trick skip करती हैं और slightly less elegant math के साथ जीती हैं।
rem कब use करें, px कब, Comeau का framing
Josh W. Comeau का article «px or rem?» (May 2022, updated May 2025) इस decision के लिए most useful single-question heuristic offer करता है। पूछें: «Should this value scale up as the user increases their browser's default font size?» यदि हां, rem use करें। यदि नहीं, px use करें।
उस test से:
- rem के लिए use करें: font-size, vertical margins/padding (जो type rhythm से tied हैं), button widths और अन्य content-shaped containers, line-length max-widths, breakpoints (ताकि layout low-vision users के लिए सही zoomed-in size पर shift करे)।
- px के लिए use करें: borders (1px hairline hairline रहनी चाहिए), horizontal padding/decoration, shadow radii, image sizes जब image का fixed pixel intent हो, fine icon dimensions।
Single-question test codebase में हजारों decisions में consistent answers produce करता है, जो real win है, resulting style sheets दोनों zoom और font-size customisation के under users की expectation के अनुसार behave करती हैं।
Tailwind CSS 4 rem-everywhere गया
Tailwind CSS v4.0 (January 2025) fully rem-based default scale ship किया। हर typography token (text-xs 0.75rem से text-9xl 8rem तक) और हर spacing token (p-1 0.25rem, p-4 1rem, m-8 2rem) out of the box rem में है। Tailwind 4 deliberately <html> root को browser default 16px पर रखता है (वे explicitly 62.5% trick apply नहीं करते) ताकि user की accessibility preferences cleanly cascade हों। करोड़ों projects अब default में rem-based design systems ship करती हैं, जो strongest argument है कि ecosystem converge हो गया है।
Default 16px Root पर Conversion Table
| Pixels | Rem | सामान्य उपयोग |
|---|---|---|
| 8 px | 0.5 rem | Base unit का आधा, small spacing |
| 12 px | 0.75 rem | कैप्शन / महीन छपाई |
| 14 px | 0.875 rem | द्वितीयक text |
| 16 px | 1 rem | Body text डिफ़ॉल्ट |
| 18 px | 1.125 rem | थोड़ा जोर दिया हुआ body |
| 20 px | 1.25 rem | मुख्य paragraph |
| 24 px | 1.5 rem | H4 heading; बड़ा UI text |
| 32 px | 2 rem | H3 हेडिंग |
| 48 px | 3 rem | H2 / hero हेडिंग |
| 64 px | 4 rem | H1 / display हेडिंग |
rem Modern Toolkit में कहाँ Fit होता है
Rem type और type-anchored spacing के लिए right default है, लेकिन यह हर layout problem का answer नहीं है। Modern toolbox में ये भी शामिल हैं:
- clamp() fluid typography के लिए,
font-size: clamp(1rem, 0.8rem + 1vw, 1.5rem)rem floor और ceiling set करता है viewport-driven middle के साथ। CSS यूनिट कन्वर्टर - Viewport units (
vw,vh, और newersvh/lvh/dvhmobile के लिए), hero sections और full-bleed elements के लिए जो type की बजाय viewport के साथ scale होनी चाहिए। - Container query units (
cqw,cqh), component-driven design के लिए जहाँ same component different widths पर appear हो सकता है।
बाकी सब के लिए (body text, headings, paddings, button widths, breakpoints) rem least resistance का path है और most accessible default।
More Questions
क्या होगा यदि मेरा Project Non-default Base Font Size Use करता है?
ऊपर Base font size field को वो value change करें जो आपके project का html { font-size: … } resolve करता है। Conversion math rem = px ÷ base रहता है base कोई भी हो। यदि आपका codebase 18px use करता है, 32px 1.78rem बन जाता है; 10px पर (62.5% trick) यह 3.2rem बन जाता है। ध्यान रखें कि root font-size override करने के accessibility implications हैं उन users के लिए जो browser default customise करते हैं, ऊपर 62.5% trick discussion देखें।
0.625rem Exactly 10px पर क्यों नहीं Render होता?
यह होता है, mathematically, default 16px root पर, 0.625 × 16 = 10। लेकिन browsers subpixel precision पर render करते हैं और final values को whole device pixels पर snap कर सकते हैं, इसलिए 0.625rem border कभी-कभी hardcoded 10px border से slightly different appear हो सकती है monitor DPR के depending पर। Pixel-perfect 1-pixel hairlines के लिए, directly 1px use करें; बाकी सब के लिए, rem-based value ठीक है।
क्या मैं Same Stylesheet में rem और px Mix कर सकता हूं?
हां, और आपको करना चाहिए। उन चीज़ों के लिए rem use करें जो user की font-size preference के साथ scale होनी चाहिए (typography, vertical rhythm, breakpoints) और उन चीज़ों के लिए px जो नहीं होनी चाहिए (borders, icon details, decorative shadows)। Comeau का «should this scale?» question practical filter है; answer almost every time cleanly एक unit या दूसरी में map होता है।
क्या Build Tools px को rem में Automatically Convert करते हैं?
हां, postcss-pxtorem और postcss-rem-to-responsive-pixel जैसे PostCSS plugins आपके authored CSS में px values को build step के दौरान rem में rewrite कर सकते हैं, configurable thresholds के साथ (जैसे, «convert anything ≥ 12px»)। ये existing px-heavy codebase migrate करते समय useful हैं। इस page जैसा live converter अभी भी one-offs, design-spec lookups, और math hand से सीखने के लिए useful है।
क्या कुछ Server को Send होता है?
नहीं। Conversion एक division है, pure JavaScript arithmetic जो आपके browser में locally run होती है। आपके input के बारे में कुछ भी page नहीं छोड़ता; tool एक बार load होने के बाद offline काम करता है।