CSS Units Converter (px, em, rem, vw)

How CSS Length Units Relate and How to Convert Them

CSS offers about a dozen ways to express a length, and the choice affects how your layout behaves when a user enlarges their text or rotates a tablet. This converter translates one value into px, em, rem, pt, percentage, vw and vh simultaneously, using a base font size and viewport dimensions you set so the numbers match your real project rather than a generic default. Front-end developers translating a Figma spec into responsive CSS, anyone migrating a stylesheet from pixels to rem for accessibility, and designers checking what 5vw actually measures on a laptop all want the same thing, which is the arithmetic done once and correctly. The units split into absolute and relative. A pixel is absolute in CSS terms and does not respond to user font settings, which is why it suits borders and hairlines but not body text. A rem is relative to the root element font size, so with the browser default of 16px one rem is 16px and the conversion is a plain division by the base. An em is relative to the font size of the element itself, which makes it useful for component-scoped spacing but means it compounds when elements nest, so 1.2em inside another 1.2em gives 1.44 times the original. Percentages behave similarly against a parent. Viewport units are relative to the window: 1vw is one hundredth of the viewport width and 1vh one hundredth of the height. Points are a print unit where 1pt is one seventy-second of an inch, which at the standard 96 DPI works out to exactly 1.333px, so 18pt equals 24px. Convert something specific. Take 24px with a base font size of 16px and a viewport of 1440 by 900. Dividing 24 by 16 gives 1.5, so the value is 1.5rem and also 1.5em at that base, and 150 percent. Multiply by 0.75 and you get 18pt for print. As a proportion of the viewport, 24 divided by 1440 times 100 is 1.667vw, and against the height it is 2.667vh. Now go the other way with a fluid heading: 5vw at that same 1440-pixel viewport resolves to 72px, which looks impressive on a laptop but collapses to 19px on a 375-pixel phone, which is why raw vw for typography needs a clamp around it. Practical situations. A developer converting a design system from pixels to rem runs every spacing token through once and gets a consistent scale that honours a user who has set their browser font to 20px. Someone building a full-height landing section uses 100vh, then checks the pixel equivalent to confirm the content still fits above the fold on a 900-pixel laptop. A print stylesheet author converts body copy to points because print output is measured in physical units rather than device pixels. A developer debugging why nested list indentation keeps growing works out that three levels of em have quietly compounded. Two things to get right. Rem for typography and spacing is the accessibility-friendly default, because a user who increases their browser font size scales the whole interface, whereas a pixel-based layout ignores them entirely; that single choice is the most common accessibility improvement in a stylesheet. The pitfall is em compounding, and it produces bugs that feel haunted: a padding of 1em on a nested component inherits a font size you did not intend and the spacing drifts at each level. Use rem unless you specifically want the scaling relationship. Also remember 100vh on mobile browsers historically included the address bar area, which is why the dvh unit exists, so test full-height sections on a real phone. All calculation runs in your browser and nothing is uploaded.

🔥 Trending Tools