CSS Units Converter
Convert between different CSS measurement units instantly. Essential tool for responsive web design and cross-browser compatibility.
📐CSS Units Converter
Common Values
All Conversions
Spacing Scale (rem)
CSS Units Guide
Relative Units
- rem: Relative to root font-size
- em: Relative to parent font-size
- %: Relative to parent
Viewport Units
- vw: 1% of viewport width
- vh: 1% of viewport height
- vmin/vmax: Smaller/larger
Absolute Units
- px: Pixels (device pixels)
- pt: Points (1/72 inch)
- in/cm/mm: Physical units
CSS Units Overview
CSS provides various units for expressing lengths and sizes. Understanding these units is crucial for creating responsive, accessible, and maintainable web designs.
Units are divided into two categories: absolute units (like px, pt) that have fixed sizes, and relative units (like em, rem, %) that scale based on other elements or viewport.
When to Use Each Unit
- •px: Fine control, borders, small precise elements
- •em: Component-based sizing relative to parent
- •rem: Consistent sizing relative to root font
- •%: Flexible layouts relative to parent
- •vh/vw: Full-screen layouts and responsive design
CSS Units Reference
Absolute Units
- • px - Pixels (most common)
- • pt - Points (1pt = 1.33px)
- • pc - Picas (1pc = 16px)
- • in - Inches (1in = 96px)
- • cm - Centimeters
- • mm - Millimeters
Relative Units
- • em - Relative to parent font size
- • rem - Relative to root font size
- • % - Percentage of parent
- • ex - x-height of font
- • ch - Width of "0" character
Viewport Units
- • vw - Viewport width (1vw = 1%)
- • vh - Viewport height (1vh = 1%)
- • vmin - Min viewport dimension
- • vmax - Max viewport dimension
- • vi - Inline viewport size
- • vb - Block viewport size
Responsive Design Tips
Best Practices
- •Use rem for typography to maintain consistent scaling
- •Use % or vw/vh for responsive layouts
- •Use px for precise details like borders and shadows
- •Combine units strategically for optimal results
Common Conversions
- •16px = 1rem (default browser font size)
- •100vw = 100% of viewport width
- •1em = current element's font size
- •62.5% on html = 10px base (easy rem calculation)
Accessibility Considerations
Font Scaling
Users may adjust their browser's default font size for better readability. Using relative units like rem and em ensures your design scales appropriately.
Avoid using px for font sizes as it prevents user customization and can harm accessibility.
Responsive Design
Viewport units help create truly responsive designs that adapt to any screen size, from mobile phones to large desktop monitors.
Be cautious with viewport units for text sizes as they may become too small on mobile devices.
How CSS Units Work
The Mathematics Behind CSS Unit Conversion
CSS unit conversion is based on straightforward mathematical relationships, but understanding these relationships is crucial for responsive design. Absolute units like pixels (px) serve as the foundation. By CSS specification, 1 inch equals exactly 96 pixels, 1 centimeter equals 37.8 pixels, and 1 point equals 1.33 pixels. These conversions remain constant regardless of screen size or resolution.
Relative units require contextual calculation. The em unit equals the computed font size of the element. If a parent has font-size: 16px and a child specifies font-size: 2em, the child's font size becomes 32px (16 × 2). This compounding effect means deeply nested em values multiply: if a grandchild uses 1.5em, it becomes 48px (16 × 2 × 1.5). This is why em can be tricky—the reference point changes with each level of nesting.
The rem unit simplifies relative sizing by always referencing the root element's font size. If the html element has font-size: 16px, then 1rem always equals 16px anywhere in the document, regardless of nesting. This makes rem predictable and preferred for most use cases. To calculate rem from pixels: rem = px / root_font_size. For 24px with a 16px root, that's 24 / 16 = 1.5rem.
Viewport units are percentages of the viewport dimensions. 1vw equals 1% of the viewport width, 1vh equals 1% of the viewport height. On a 1920px wide screen, 50vw equals 960px. On a 375px wide mobile screen, 50vw equals 187.5px. The calculation is simple: vw_pixels = (vw_value / 100) × viewport_width. This makes viewport units perfect for full-screen layouts but dangerous for text sizing without bounds.
Percentage units reference the parent element's corresponding dimension. For width and margin/padding horizontal values, percentage refers to parent width. For height with an explicitly sized parent, percentage refers to parent height. But height percentages fail when the parent has automatic height, because the calculation becomes circular (parent height depends on child, child depends on parent). Understanding what dimension a percentage references prevents common layout bugs.
Historical Evolution of CSS Measurements
CSS1 (1996) introduced the fundamental units we still use today: px, em, pt, cm, mm, in, and percentage. The specification inherited these from print media and desktop publishing. Pixels were chosen as the primary screen unit because they corresponded to physical screen pixels on the 72-96 DPI monitors common in the 1990s. This worked well when screens were uniform and zoom functionality didn't exist.
The introduction of high-DPI displays (Retina, 4K, etc.) challenged the pixel paradigm. A CSS pixel no longer equals a physical pixel—on a 2x Retina display, one CSS pixel equals four device pixels (2×2). The CSS Working Group redefined the reference pixel as 1/96th of an inch at 96 DPI, making it a fixed angular measurement rather than a physical pixel. This abstraction maintains consistent sizing across different screen densities.
CSS3 introduced viewport units (vw, vh, vmin, vmax) in 2011 to support responsive design. Before viewport units, creating full-height layouts required JavaScript to measure window height. The viewport units solved this elegantly: 100vh always equals the full viewport height. However, mobile browsers introduced quirks—the address bar causes vh to change when scrolling, leading to layout shifts. This spawned proposals for new units like dvh (dynamic viewport height) to handle these cases.
The rem unit was added to address em's compounding complexity. Developers found em values difficult to predict in complex layouts where nesting depth varied. rem provided the relative sizing benefits of em without the compounding effect. Today, rem is the recommended unit for typography, while em remains useful for component-specific sizing where you want child elements to scale with the parent.
Recent additions include container query units (cqw, cqh) which reference the size of a container element rather than the viewport. These enable true component-based responsive design—a card component can adapt to its container size regardless of viewport size. The ch unit (width of the "0" character) enables typographically-aware layouts, useful for setting max-width on text blocks to ensure optimal line length for readability.
Practical Conversion Strategies and Patterns
A common conversion strategy is the 62.5% technique: setting html { font-size: 62.5%; } makes the root font size 10px (62.5% of browser default 16px). This simplifies rem calculations—1rem = 10px, 1.6rem = 16px, 2.4rem = 24px. The math becomes trivial: divide pixel values by 10 to get rem. However, this technique can break user font size preferences, so some developers prefer setting the root to 100% and using larger rem decimals (1rem = 16px, 1.5rem = 24px).
Converting between absolute and viewport units requires knowing the viewport size. To convert px to vw: vw = (px / viewport_width) × 100. For a 1920px viewport, 100px equals (100 / 1920) × 100 = 5.208vw. But this conversion is viewport-dependent—the same 100px on a 375px mobile viewport becomes 26.67vw. This is why viewport units work best for layout dimensions (width, height, padding) rather than fixed-size elements like icons.
Fluid typography combines viewport units with calc() for responsive text that scales smoothly between minimum and maximum sizes. The formula: font-size: calc([min]rem + ([max] - [min]) × ((100vw - [min-width]rem) / ([max-width] - [min-width]))). For example, to scale from 16px to 24px between 320px and 1920px viewport widths, you'd use calc(1rem + 0.5 × ((100vw - 20rem) / 100)). This creates text that grows smoothly without media query breakpoints.
The clamp() function simplifies fluid sizing: clamp(min, preferred, max). For fluid typography, clamp(1rem, 2vw, 2rem) ensures font size never goes below 16px or above 32px, but scales with viewport width in between. This three-value approach is more maintainable than complex calc() expressions and handles edge cases automatically. It's become the modern standard for fluid responsive design.
When migrating between unit systems, use CSS preprocessors or build tools. Sass functions can convert px to rem automatically: @function px-to-rem($px) { @return ($px / 16) + rem; }. PostCSS plugins like postcss-pxtorem can convert entire stylesheets. These tools prevent manual conversion errors and make unit system changes project-wide. Always test conversions thoroughly, especially for layouts that depend on specific dimensions.
Browser Rendering and Unit Resolution
Browsers convert all CSS units to pixels during layout calculation. When you specify width: 10rem with a 16px root font, the browser immediately calculates 160px. This pixel value flows through the box model calculations (content, padding, border, margin) and determines the element's final rendered size. Understanding this helps debug layout issues—browser DevTools show computed pixel values, which you can trace back to your unit specifications.
The cascade affects unit computation order. Inherited properties like font-size cascade down the DOM tree. If a parent has font-size: 2em and child has font-size: 1.5em, the browser first computes the parent's absolute font size, then uses that as the reference for the child's em value. This top-down computation means changing a parent's font size recalculates all descendants—potentially expensive for deeply nested structures.
Subpixel rendering handles fractional pixel values. When calculations result in 15.7px, browsers must decide whether to round, ceil, floor, or use subpixel anti-aliasing. Different browsers handle this differently, leading to subtle cross-browser inconsistencies. Text might appear blurry when positioned at fractional pixels. Some developers avoid this by using rem values that result in whole pixel numbers, like 0.875rem (14px) instead of 0.8rem (12.8px).
Zoom functionality multiplies all pixel values. When a user zooms to 150%, a 16px font becomes 24px. But viewport units don't change—100vh remains 100% of the viewport height regardless of zoom level. This can break layouts that mix viewport units with other units. Test your layouts at various zoom levels (browsers support 50% to 500%) to ensure they remain functional for users with vision impairments who rely on browser zoom.
Performance considerations vary by unit type. Viewport units force layout recalculation on viewport resize, potentially expensive for complex pages. Percentage-based layouts require parent dimension lookups. Fixed pixel values are cheapest to compute but least flexible. In practice, these performance differences are negligible for most websites. Prioritize maintainability and flexibility over micro-optimization unless profiling reveals unit calculations as a bottleneck.
Real-World Responsive Design Applications
Modern responsive frameworks rely heavily on unit strategies. Bootstrap uses rem for typography and spacing, ensuring consistent scaling when users change default font sizes. Tailwind CSS provides utility classes for various units but recommends rem for spacing and sizing. These frameworks demonstrate best practices: rem for typography and component spacing, percentages or viewport units for layout widths, pixels for borders and shadows that should maintain absolute size.
Mobile-first design prioritizes viewport units and percentages. On mobile, horizontal space is precious—width: 100% or width: 100vw ensures full-width layouts. But pure percentage/viewport layouts can look stretched on large screens. The solution: max-width in rem or ch units. A content block might use width: 100%; max-width: 65ch; to fill mobile screens but maintain readable line length on desktop, where ch units ensure optimal 60-75 character lines.
Component libraries must handle unit conversion carefully. When building a button component, should padding be em or rem? em makes the button scale with its font size—useful for buttons with varying text sizes. rem keeps padding consistent across the application regardless of context. Neither is universally correct; the choice depends on whether you want component-level or application-level consistency. Document these decisions for your team.
Print stylesheets often convert web units back to print units. When users print web pages, pt (points) and cm (centimeters) produce more predictable results than px or rem. A print stylesheet might convert font-size: 1rem to font-size: 12pt and width: 100% to width: 21cm (A4 paper width minus margins). This ensures printed output matches the physical medium's constraints rather than attempting to translate screen dimensions directly.
Accessibility tools depend on proper unit usage. Screen readers don't care about units, but screen magnifiers do. When users with low vision use magnification software, rem-based layouts scale smoothly while px-based layouts may break or require horizontal scrolling. This makes rem the most accessible choice for dimensions that should scale with user preferences. Never use px for font sizes in production—it's one of the most common accessibility violations.
Advanced Units and Future Specifications
Container query units (cqw, cqh, cqi, cqb) represent a paradigm shift in responsive design. Instead of sizing based on viewport, elements can respond to their container's size. A card component might use font-size: clamp(1rem, 3cqw, 1.5rem) to scale typography based on card width, not viewport width. This enables truly modular components that adapt to their context—a wide sidebar versus a narrow column—without media queries.
The new dynamic viewport units (dvh, dvw, dvi, dvb) solve mobile browser chrome issues. On mobile, 100vh can be problematic because the address bar shrinks on scroll, changing the viewport height. dvh accounts for this, always representing the current visible viewport height. Similarly, svh (small viewport height) represents the smallest possible viewport (address bar visible) and lvh (large viewport height) represents the largest (address bar hidden). Choose the variant that matches your design intent.
The lh unit equals the computed line-height of the element. This enables vertical rhythm systems where margins and padding align with text lines. For example, margin-bottom: 1lh creates spacing exactly equal to one line of text, regardless of font size changes. Combined with rlh (root line-height), you can build typographic systems that maintain consistent vertical spacing automatically as font sizes adjust.
Custom properties (CSS variables) can store unit values and enable dynamic calculations. You might define --base-spacing: 1rem and use it throughout your stylesheet: padding: var(--base-spacing). Changing the variable updates all references. Combined with calc(), you can create spacing scales: --spacing-2: calc(var(--base-spacing) * 2). This approach centralizes unit decisions and makes global adjustments trivial.
Future CSS specifications propose even more units. The rcap unit would represent the height of capital letters in the root font, useful for precise typographic alignment. The ric unit (root inline-size of "水" character) helps with CJK typography. As CSS evolves to support more languages and contexts, the unit system grows more sophisticated. Understanding fundamental units positions you to adopt new units as they achieve browser support and solve current design challenges.
FAQ
Should I use em or rem for font sizes?
Use rem for most typography to ensure predictable sizing and accessibility. rem always references the root font size, making it easy to calculate and update globally. Use em only when you want component-specific scaling—for example, button padding that should scale with the button's font size. Never use px for font sizes as it prevents users from adjusting text size in their browser settings.
Why does my layout with 100vh have scrollbars on mobile?
On mobile browsers, 100vh includes the space behind the address bar and bottom navigation, which appear and disappear as you scroll. This causes 100vh to be larger than the visible viewport, creating scrollbars. Use the new dynamic viewport units: 100dvh adjusts to the current visible height, 100svh represents the smallest height (with UI visible), and 100lvh represents the largest height (with UI hidden).
How do I convert pixels to rem in my head?
With the default 16px root font size, divide pixels by 16. So 24px = 1.5rem, 32px = 2rem, 48px = 3rem. For easier mental math, use the 62.5% trick: set your root font to 62.5% (10px), then divide pixels by 10. But remember this can affect accessibility if not done carefully. Better yet, use CSS preprocessor functions or build tools to convert automatically.
When should I use viewport units vs percentages?
Use viewport units (vw, vh) for elements that should always relate to the viewport size regardless of parent, like full-screen overlays or hero sections. Use percentages for elements that should scale with their parent container, like columns in a grid or widths within a specific component. Percentages enable modular, reusable components while viewport units are better for full-page layouts.