क्या मैं इसे मोबाइल डिवाइस पर उपयोग कर सकता हूँ?

Yes, this tool works on any device with a modern browser including phones and tablets.

क्या यह टूल ऑफ़लाइन काम करता है?

Yes, once the page has loaded, the tool works entirely in your browser without needing an internet connection. All processing is done locally with JavaScript.

Is there a character or line limit?

There is no hard limit. The tool can handle files with tens of thousands of lines, though very large inputs may slow down depending on your browser and device.

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

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

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

रूट फ़ॉन्ट आकार (px)

पैरेंट फ़ॉन्ट आकार (px)

व्यूपोर्ट चौड़ाई (px)

व्यूपोर्ट ऊँचाई (px)

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

मान

से

परिणाम

CSS इकाई संदर्भ

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

px · पिक्सेल (1/96 इंच)
pt · पॉइंट (1/72 इंच)
cm · सेंटीमीटर
mm · मिलीमीटर
in · इंच

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

rem · रूट फ़ॉन्ट आकार के सापेक्ष
em · पैरेंट फ़ॉन्ट आकार के सापेक्ष
vw · व्यूपोर्ट चौड़ाई का 1%
vh · व्यूपोर्ट ऊँचाई का 1%
vmin · सबसे छोटे व्यूपोर्ट आयाम का 1%
vmax · सबसे बड़े व्यूपोर्ट आयाम का 1%
% · पैरेंट तत्व का प्रतिशत

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

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

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

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

The CSS reference pixel, the keystone of every absolute unit

CSS absolute units (in, cm, mm, Q, pt, pc, px) are anchored to the CSS reference pixel. The W3C CSS Values and Units Module Level 3 defines it as "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." For an arm's length of about 28 inches that visual angle is roughly 0.0213°, equivalent to about 0.26 mm of physical screen width at typical viewing distance, and the spec illustrates that the same visual angle translates to roughly 1.3 mm at 12 feet, which is why projector and TV pixels can be physically larger but still count as one CSS pixel each.

For screens, the spec defines CSS 1in = 96 px rather than deriving from real screen inches. This means the conversions in the table above are exact and do not depend on display DPI: 12 pt is always 16 px, 1 pc is always 16 px, 1 mm is always about 3.78 px. On a high-DPI display (Retina, 4K), the operating system maps each CSS pixel to whatever device pixels best approximate the visual angle, typically 2 device pixels per CSS pixel on a Retina MacBook, 3 on an iPhone Pro, 1.5 on a Windows desktop at 150% scaling. A crisp 1px border on a Retina screen takes 2 device pixels.

Font-relative units

These resolve against typography rather than physical inches. They are the bedrock of accessible, scalable layouts.

em is the cornerstone, with surprising depth of history, it predates CSS by roughly 500 years. In movable-type printing (post-Gutenberg, c. 1450), the "em quad" was a square block of metal whose width equalled the height of the type body, historically approximating the width of the capital M. CSS borrows the abstraction: 1em equals the computed font-size of the current element. The famous gotcha is that nested font-size: 1.2em declarations multiply, a child of 1.2em inside a parent of 1.2em renders at 1.44× the grandparent.

rem ("root em") was added in CSS3 to solve exactly that compounding problem. 1rem equals the font-size of the root <html> element, unaffected by parent nesting. Browsers default the root to 16 px unless the user overrides it, so 1rem = 16px in default conditions. rem shipped in Safari 4.1 and Firefox 3.6 in 2010, IE9 in March 2011, IE8 never supported it, which forced px fallbacks until around 2014.

Newer font-relative units (CSS Values 4) include ch (the width of the "0" character in the current font, useful for line-length max-widths like max-width: 60ch or 66ch, which sit in the typographically ideal 45–75 character reading range), ex (x-height of the font), cap (capital height), ic (advance of the CJK 水 ideograph), and lh / rlh (the computed line-height of the element / root, useful for vertical rhythm).

Viewport-percentage units (and the mobile address-bar problem)

The classic four, vw, vh, vmin, vmax: represent 1% of viewport width, 1% of viewport height, 1% of the smaller of the two, and 1% of the larger. At 1920 × 1080: 1vw = 19.2px, 1vh = 10.8px.

100vh was a long-standing pain on mobile because both iOS Safari and Chrome Mobile show a URL bar that retracts as you scroll. Browsers had to choose: make 100vh equal the short viewport (URL bar visible (content gets clipped after scroll) or the tall one (URL bar hidden) large empty space on initial paint). iOS Safari chose the tall behaviour, leaving developers debugging "why is my hero section taller than the screen?" for years.

The Interop 2022 effort (Apple, Google, Igalia, Microsoft, Mozilla and others) added new viewport variants in March 2022 to fix this:

Small viewport (svw / svh / svmin / svmax), assumes the browser UI is fully expanded; the smallest possible viewport. Stable on initial paint.
Large viewport (lvw / lvh / etc.), assumes the browser UI is fully retracted; the largest possible viewport.
Dynamic viewport (dvw / dvh / etc.), updates live as UI shrinks and expands. Best fit, but can cause repaints during scroll.

Practical recipe: min-height: 100svh on a hero section so it doesn't clip on iOS, or height: 100dvh on a fullscreen modal. Safari shipped support first (15.4, March 2022); Firefox 101 (May 2022); Chrome and Edge 108 (December 2022). Global support is now widespread.

Container query units

A newer family, cqw, cqh, cqi, cqb, cqmin, cqmax: lets an element size itself based on its container rather than the viewport. Essential for component-driven design where the same component might appear at 300 px wide in a sidebar and 900 px wide in a main column. The unit evaluates against the nearest ancestor container with container-type set; if no eligible container exists, the spec falls back to the small viewport unit on that axis. Container queries (and units) shipped in Chromium 105 in 2022, Safari 16 in September 2022, and Firefox 110 in February 2023, becoming Baseline newly available in 2023.

Percentages, and why they're not really a length

Percentages aren't a length unit per se, they're a separate value type that resolves contextually:

On width / height: percentage of the parent's inline / block size.
On font-size: percentage of the parent's computed font-size.
On line-height: percentage of the element's own font-size.
On margin and padding on all four sides: percentage of the parent's inline size (i.e., width). This is the source of the famous "vertical margin in % equals horizontal" surprise.
On transform: translate(): percentage of the element's own dimensions.

Because of this contextual resolution, % can't simply be converted to px without knowing the parent dimension, the converter above asks for it explicitly.

Practical guidance) when to use what

Use rem for font-size. It honours the user's browser default font setting, a real accessibility win, because visually impaired users can scale globally instead of per-site.
Use em for component-internal proportions: icon sizes that should match button text, padding inside a button that scales with the text.
Avoid px on font-size. Browser zoom helps but only on a per-site basis; rem also respects the user's default font size override.
px is fine for borders, sharp decorative elements, and shadows where physical thickness matters more than scaling.
% for fluid layouts where children must fill their parent.
vw / vh for hero sections, full-bleed backgrounds, and modals: but reach for svh or dvh instead of vh on anything that touches the bottom of mobile screens.
vmin for square-aspect elements (avatars, splash screens) so they fit within both axes.
ch for line-length max-widths on prose: max-width: 60ch or 66ch sits in the ideal-reading range.

Fluid typography with clamp()

clamp(MIN, PREFERRED, MAX) returns the preferred value bounded by the floor and ceiling. The classic fluid-type pattern combines a rem floor and ceiling with a vw-driven scaling middle:

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

The middle term scales linearly with the viewport, while the rem-based floor and ceiling prevent extreme sizes and preserve user font scaling. clamp() reached Baseline widely-available in July 2020 (Chrome 79, Firefox 75, Safari 13.1). Tools like Utopia (utopia.fyi) and fluid-type-scale.com take min / max viewport widths, min / max font sizes, and a modular scale ratio (1.2, 1.25, 1.333, 1.5, golden) and emit ready-to-paste declarations.

Accessibility, WCAG SC 1.4.4 Resize Text

The standard requires that text be enlargeable to 200% of original size without loss of content or functionality. It does not mandate a specific unit, but the listed sufficient techniques include "using measurements that are relative to other measurements in the content", relative units (em, rem, %) make compliance easier; pixel-only layouts can pass via browser zoom but are more fragile. The mental test: should this scale when the user enlarges their default text size? If yes, use rem. Borders, decorative padding and pure decoration can stay px.