CSS Units Converter
Convert between px, rem, em, %, vh, and vw with configurable root font-size
Context (root font-size, parent size, viewport dimensions)
How to CSS Units Converter Online
Convert any CSS length value between px, rem, em, pt, %, vh, and vw.
- Type a number into the Value input and pick the unit it's measured in.
- Read off the conversions in the rows below — all 6 other units update live.
- Open the Context panel to adjust the root font-size (default 16, matches every browser's default), the parent size in px (used for %), and viewport dimensions (used for vh/vw).
- Common context overrides: root font-size of 10 for the `1rem = 10px` design pattern, parent size matching a specific container width when computing % values for it.
- Click Copy on any row to put that converted value on your clipboard with the unit appended (e.g. `1.5rem`).
About CSS Units Converter
CSS gives you a surprising number of units to express the same physical length. A 24px font and a 1.5rem font on a default page render identically; so do 18pt, 50% of a 48px parent, 100% of itself, and various viewport-relative variants depending on the page. The right unit to use is rarely a matter of correctness — it is a matter of *which thing the value should scale with*. Get the unit right and your design respects user preferences, adapts to context, and survives a redesign. Get it wrong and everything you ship is pinned to one specific font-size and one specific viewport size forever.
The seven units this tool handles split into three categories.
**Absolute units (px, pt).** Pixels are the universal CSS reference unit — one CSS pixel is defined as 1/96 of an inch, which means it scales independently of physical screen resolution (a high-DPI Retina pixel renders as multiple device pixels, but the CSS px value stays constant). Points (pt) are a legacy typography unit at 1/72 of an inch — virtually never used for screens but still common in print stylesheets and email HTML where some mail clients have stronger pt support than px. Both units are *absolute* in the sense that 16px is always 16px regardless of context.
**Font-relative units (rem, em).** These scale with the document's typography. `rem` is relative to the root `<html>` font-size (default 16px in every browser; user-overridable via browser settings); `em` is relative to the current element's own font-size. Use rem when you want consistent sizing across your design that still respects user font-size preferences — type, padding around text, margins between content blocks, most icon sizes for inline-with-text icons. Use em when you specifically want cascading: a button that should be 2× its own font-size in padding regardless of how it's used. The accessibility upside of rem is real and substantial: increasing the browser default from 16 to 20 should make your entire design proportionally bigger; if you use px everywhere, it won't.
**Container/viewport-relative units (%, vh, vw).** Percentages are relative to the parent's corresponding dimension (width for horizontal-axis properties, height for vertical-axis, font-size for font-size). Viewport units are relative to the browser viewport: 1vh = 1% of viewport height, 1vw = 1% of viewport width. Both scale with their container automatically, making them the right pick for layouts that need to respond to container size — full-bleed sections, fluid type, sticky-bottom buttons, full-height heroes.
A subtle hazard with viewport units: **mobile browsers lie about viewport height**. iOS Safari changes 1vh based on whether the URL bar is showing, which produces frustrating layout jumps. The modern alternatives are `dvh` (dynamic — updates as browser chrome shows/hides), `svh` (small — assumes maximum chrome), and `lvh` (large — assumes minimum chrome). Use these instead of vh whenever your layout's correctness depends on actual visible viewport height. They are supported in all modern browsers as of 2023; older browsers fall back gracefully if you provide a vh fallback first.
The **context inputs** in the tool let you simulate any real setup. Setting the root font-size to 10 reflects the "1rem = 10px" pattern some teams use (set `html { font-size: 62.5% }` and 1rem becomes 10px, making the px↔rem math trivial). Setting parent size to your container's actual width gives accurate % conversions. Setting viewport dimensions to your target device produces vh/vw values that match what users will see.
A practical note on **rounding**. Browsers don't round CSS lengths — they paint sub-pixel values directly to the display pipeline, where the GPU handles antialiasing. So 1.7333px is a perfectly valid value that renders smoothly. The tool emits up to 4 fractional digits and strips trailing zeros, which keeps output compact while preserving enough precision for any practical use.
Everything runs in your browser. The conversion is a pure function under 1 KB with vitest coverage of every unit pair and edge cases (zero divisors, custom rem bases). No network requests.
Related Tools
Frequently Asked Questions
Why is 1rem usually 16 pixels?
Because every browser ships with `font-size: 16px` on the root `<html>` element by default, and 1rem is defined as 'one times the root font-size.' Users can change this default in their browser settings — increasing it to make all text larger. If you size everything in rem instead of px, your design respects that preference; if you size in px, it does not. This is the single biggest accessibility win from preferring rem over px for type and spacing.
What is the difference between em and rem?
Both are relative to a font-size, but they pick a different one. **rem** is relative to the root (`<html>`) font-size — it stays constant regardless of where the element is nested. **em** is relative to the *current element's* font-size — so it cascades. If a parent has `font-size: 20px` and a child has `padding: 1em`, the padding is 20px. If the parent's font-size changes, the child's padding follows. Most modern style guides recommend rem for almost everything and em only when you want the cascading behavior (typography inside a sized component, for example).
What is pt and why does CSS support it?
`pt` (point) is 1/72 of an inch, the traditional typography unit from the print world. CSS defines 1 inch = 96 pixels (a convention from early Windows displays), so 1pt = 96/72 ≈ 1.333 pixels. The unit survives in CSS mostly for print stylesheets (`@media print { font-size: 12pt; }`) and email HTML where Outlook and other mail clients sometimes prefer pt over px. For screens you should almost always use px or rem.
What is the parent size for %?
It depends on the property. For `width` and `padding-left`, the parent size is the parent's *width*. For `height` and `padding-top`, it is the parent's *height*. For `font-size`, it is the parent's *font-size*. The CSS spec is unintuitive here — the tool lets you set a single 'parent size in px' for the conversion, and you tell it what that value represents based on which property you're working with.
Why are my vh values different on mobile?
Mobile browsers have a famously inconsistent definition of viewport height. iOS Safari changes 1vh based on whether the URL bar is shown; Chrome on Android does similar tricks. The modern alternative is `dvh` (dynamic viewport height) and `svh`/`lvh` (small/large viewport height). This tool computes vh against your chosen viewport-height value; for cross-device CSS work, prefer dvh / svh for layouts that need to handle browser chrome reliably.
Should I use rem or px for design tokens?
Most modern design systems use **rem for everything sized by content** (font-size, line-height, padding around text, margins between content blocks) and **px for everything sized by layout** (border widths, fixed-width rails, separator lines, small icons that should not scale with text). The reasoning: rem respects user font-size preferences, which matters for accessibility; px gives pixel-perfect layout primitives that should look the same regardless of user settings.
Is anything sent to a server?
No. The conversion is a small pure function in your browser. The context values (root font-size, parent size, viewport dimensions) live in this page's React state. No network requests.