CSS यूनिट कन्वर्टर

विन्यास योग्य संदर्भ के साथ px, rem, em, vw, vh, pt, cm, mm, in और % के बीच कनवर्ट करें।

संदर्भ सेटिंग्स

रूपांतरित करें

परिणाम

CSS इकाई संदर्भ

निरपेक्ष इकाइयाँ

सापेक्ष इकाइयाँ

rem या em का उपयोग कब करें?

सुसंगत आकार (मार्जिन, पैडिंग, फ़ॉन्ट साइज़) के लिए rem का उपयोग करें · यह हमेशा रूट से संदर्भ देता है। जब आप माता-पिता के सापेक्ष आकार चाहते हैं तो em का उपयोग करें, जैसे नेस्टेड घटक जो अपने संदर्भ के अनुकूल होते हैं।

px हमेशा एक भौतिक पिक्सेल के बराबर क्यों नहीं है?

CSS px एक «संदर्भ पिक्सेल» है जिसे बाँह की दूरी पर 1/96 इंच के रूप में परिभाषित किया गया है। उच्च-घनत्व (HiDPI) स्क्रीन पर, एक CSS px 2 या 3 भौतिक पिक्सेल के अनुरूप हो सकता है।

CSS reference pixel, हर absolute unit की आधारशिला

CSS absolute units (in, cm, mm, Q, pt, pc, px) CSS reference pixel पर anchored हैं। W3C CSS Values and Units Module Level 3 इसे define करता है «the visual angle of one pixel on a device with a device pixel density of 96 dpi and a distance from the reader of an arm's length.» arm's length लगभग 28 inches के लिए वह visual angle roughly 0.0213° है, जो typical viewing distance पर physical screen width के लगभग 0.26 mm के equivalent है, और spec illustrate करती है कि same visual angle 12 feet पर roughly 1.3 mm translate होता है, इसीलिए projector और TV pixels physically बड़े हो सकते हैं लेकिन फिर भी हर एक CSS pixel count होता है।

Screens के लिए, spec CSS 1in = 96 px define करती है बजाय real screen inches से derive करने के। इसका मतलब ऊपर की table में conversions exact हैं और display DPI पर depend नहीं करतीं: 12 pt हमेशा 16 px है, 1 pc हमेशा 16 px है, 1 mm हमेशा लगभग 3.78 px है। High-DPI display (Retina, 4K) पर, operating system हर CSS pixel को उन device pixels पर map करता है जो visual angle को best approximate करती हैं, typically Retina MacBook पर per CSS pixel 2 device pixels, iPhone Pro पर 3, 150% scaling पर Windows desktop पर 1.5। Retina screen पर एक crisp 1px border 2 device pixels लेती है।

Font-सापेक्ष units

ये physical inches के बजाय typography के against resolve होते हैं। ये accessible, scalable layouts की नींव हैं।

em cornerstone है, history की surprising depth के साथ, यह CSS से roughly 500 साल पहले की है। Movable-type printing (post-Gutenberg, c. 1450) में, «em quad» metal का एक square block था जिसकी width type body की height के equal थी, historically capital M की width को approximate करती थी। CSS इस abstraction को borrow करता है: 1em current element की computed font-size के equal है। Famous gotcha यह है कि nested font-size: 1.2em declarations multiply होती हैं, 1.2em की एक child जो 1.2em की एक parent के अंदर हो वह 1.44× grandparent पर render होती है।

rem («root em») CSS3 में exactly उस compounding problem को solve करने के लिए add किया गया था। 1rem root <html> element की font-size के equal है, parent nesting से unaffected। Browsers default रूप से root को 16 px पर set करते हैं जब तक user इसे override न करे, इसलिए default conditions में 1rem = 16px। rem Safari 4.1 और Firefox 3.6 में 2010 में, IE9 में March 2011 में ship हुआ, IE8 ने कभी support नहीं किया, जिसने 2014 तक px fallbacks force किए।

Newer font-relative units (CSS Values 4) में ch (current font में «0» character की width, line-length max-widths के लिए useful जैसे max-width: 60ch या 66ch, जो typographically ideal 45-75 character reading range में होते हैं), ex (font की x-height), cap (capital height), ic (CJK ideograph का advance width), और lh / rlh (element / root की computed line-height, vertical rhythm के लिए useful) शामिल हैं।

Viewport-percentage units (और mobile address-bar problem)

Classic चार, vw, vh, vmin, vmax: viewport width का 1%, viewport height का 1%, दोनों में से smaller का 1%, और larger का 1% represent करते हैं। 1920 × 1080 पर: 1vw = 19.2px, 1vh = 10.8px।

100vh mobile पर एक long-standing pain था क्योंकि iOS Safari और Chrome Mobile दोनों एक URL bar show करते हैं जो scroll करते समय retract होती है। Browsers को choose करना था: 100vh को short viewport (URL bar visible, content scroll के बाद clip) या tall viewport (URL bar hidden, initial paint पर large empty space) के equal बनाएं। iOS Safari ने tall behaviour choose किया, developers को सालों तक «why is my hero section taller than the screen?» debug करवाते हुए।

Interop 2022 effort (Apple, Google, Igalia, Microsoft, Mozilla और अन्य) ने March 2022 में इसे fix करने के लिए new viewport variants add किए:

Practical recipe: hero section पर min-height: 100svh ताकि iOS पर clip न हो, या fullscreen modal पर height: 100dvh। Safari ने पहले support ship किया (15.4, March 2022); Firefox 101 (May 2022); Chrome और Edge 108 (December 2022)। Global support अब widespread है।

Container query इकाइयाँ

एक newer family, cqw, cqh, cqi, cqb, cqmin, cqmax: एक element को viewport के बजाय अपने container के आधार पर size करने देती है। Component-driven design के लिए essential जहां same component sidebar में 300 px wide और main column में 900 px wide appear हो सकता है। Unit container-type set किए गए nearest ancestor container के against evaluate होता है; यदि कोई eligible container नहीं है, तो spec उस axis पर small viewport unit पर fallback करता है। Container queries (और units) 2022 में Chromium 105 में, September 2022 में Safari 16 में, और February 2023 में Firefox 110 में ship हुए, 2023 में Baseline newly available बनते हुए।

Percentages, और ये really एक length क्यों नहीं हैं

Percentages per se एक length unit नहीं हैं, ये एक separate value type हैं जो contextually resolve होती हैं:

इस contextual resolution के कारण, % को simply px में convert नहीं किया जा सकता बिना parent dimension जाने, ऊपर का converter इसके लिए explicitly पूछता है।

Practical guidance: कब क्या use करें

clamp() के साथ Fluid typography

clamp(MIN, PREFERRED, MAX) preferred value को floor और ceiling से bounded return करता है। Classic fluid-type pattern एक rem floor और ceiling को vw-driven scaling middle के साथ combine करता है:

h1 { font-size: clamp(1.8rem, 1.2rem + 2.5vw, 3rem); }

Middle term viewport के साथ linearly scale करता है, जबकि rem-based floor और ceiling extreme sizes prevent करते हैं और user font scaling preserve करते हैं। clamp() July 2020 में Baseline widely-available पहुंचा (Chrome 79, Firefox 75, Safari 13.1)। Utopia (utopia.fyi) और fluid-type-scale.com जैसे tools min / max viewport widths, min / max font sizes, और एक modular scale ratio (1.2, 1.25, 1.333, 1.5, golden) लेते हैं और ready-to-paste declarations emit करते हैं।

पहुँच-योग्यता, WCAG SC 1.4.4 Resize Text

Standard require करता है कि text को बिना content या functionality के loss के original size का 200% तक enlarge किया जा सके। यह कोई specific unit mandate नहीं करता, लेकिन listed sufficient techniques में «content में अन्य measurements के relative measurements का उपयोग करना» शामिल है, relative units (em, rem, %) compliance को आसान बनाते हैं; pixel-only layouts browser zoom के माध्यम से pass कर सकते हैं लेकिन अधिक fragile हैं। Mental test: क्या यह scale होना चाहिए जब user अपना default text size बढ़ाए? यदि हां, तो rem use करें। Borders, decorative padding और pure decoration px पर रह सकते हैं।

अधिक प्रश्न

मेरी screen पर 1in really एक inch क्यों नहीं है?

क्योंकि CSS spec absolute units को physical inches के बजाय visual angle reference पर anchor करती है। एक CSS 1in exactly 96 CSS pixels के रूप में defined है, जिसे browser उन device pixels पर map करता है जो typical viewing distance पर reference को best approximate करती हैं। अधिकांश monitors पर यह real inch के close आता है, लेकिन room के पार देखे जाने वाले TV पर यह physically बड़ा होगा, और आपकी lap पर high-DPI laptop पर यह slightly smaller हो सकता है। Real physical measurement के लिए, screen के खिलाफ ruler use करें।

«62.5% trick» जिसके बारे में लोग कभी-कभी mention करते हैं, वह क्या है?

एक widely-used pattern: html { font-size: 62.5%; }। क्योंकि 62.5% × 16 = 10, यह 1rem = 10px बनाता है: mental math के लिए convenient (1.6rem = 16px, 2.4rem = 24px)। इस पर debate है; opponents argue करते हैं कि यह user के preferred default font size को override करता है और accessibility के लिए mildly user-hostile है। कई modern teams एक ratio choose करते हैं जिसमें user override explicitly preserved हो (जैसे, body font-size rem में set करना ताकि cascade user के default को respect करे)।

vw बनाम cqw कब use करना चाहिए?

vw तब use करें जब size viewport track करना चाहिए (full-bleed hero text, fullscreen modals)। cqw तब use करें जब size component के container track करना चाहिए: उदाहरण के लिए एक card title जो main column में होने पर बड़ा और sidebar में होने पर छोटा हो, viewport size की परवाह किए बिना। Container query units 2022-2023 में ship हुए और लगभग किसी भी समय सही answer हैं जब आप otherwise किसी single component पर media-query-driven font scale के लिए reach करते।

@media queries में dpi और dppx में क्या अंतर है?

दोनों resolution express करते हैं। dppx का मतलब है «dots per CSS pixel», 1dppx = 96dpi, क्योंकि CSS 96 px per inch define करता है। @media (min-resolution: 2dppx) Retina-class displays target करता है जहां हर CSS pixel को कम से कम 2 device pixels के साथ render किया जाता है। dppx use करना generally preferred है क्योंकि यह dpi-vs-CSS-inch confusion से clear रहता है।

क्या कुछ server पर भेजा जाता है?

नहीं। Conversions simple JavaScript arithmetic हैं जो locally आपके browser में run होती हैं। आपके inputs के बारे में कुछ भी कहीं नहीं भेजा जाता; page एक बार load होने पर offline काम करता है।

संबंधित टूल

मुफ़्त PX से REM कन्वर्टर Border Radius जनरेटर मुफ़्त इकाई कनवर्टर ऑनलाइन