PX–REM-muunnin

Convert px to rem and Back, Instantly

This px to rem converter keeps px, rem, em and pt in sync against whatever root font size you choose. Edit any field and the rest update live, so going from a pixel design mockup to scalable CSS rem units — or back from rem to px — takes no mental arithmetic. It's a fast, free CSS unit converter that runs entirely in your browser with nothing uploaded.

The reference table below the converter lists all the common px values you need day-to-day — copy any result with a click. Change the root font size and the entire table recalculates instantly, making it easy to switch between a 16px project and a 10px (62.5% trick) project.

The px to rem Formula Explained

The conversion is simple: rem = px ÷ root font size. Browsers default to a 16px root, so 16px = 1rem, 24px = 1.5rem, and 40px = 2.5rem. To reverse: px = rem × root, so 0.875rem × 16 = 14px. Because the converter is bidirectional, you never have to remember which direction you're working in — just type into the field you know and the others update.

The 62.5% trick simplifies this: set html { font-size: 62.5%; } to make the root 10px, then rem values map cleanly to multiples of 10. 1.6rem = 16px, 2.4rem = 24px, 3.2rem = 32px. Switch to the 10px preset here to see the clean mapping across all common values.

px, rem and em — What's the Difference?

px is an absolute unit: 16px is always 16px. rem is relative to the root (html) element's font size, giving one consistent anchor for the whole page. em is relative to the font size of its own parent, so it compounds as you nest elements — a paragraph inside a section at 1.2em inside an article at 1.2em gives 1.2 × 1.2 = 1.44em, while 1.44rem would be a flat 1.44× the root regardless of nesting depth.

The tool also shows pt (1px = 0.75pt) for print-style values. At a 16px root with no nesting, 16px, 1rem and 1em are all equal — the difference only becomes visible once parent font sizes change or a user adjusts their browser's default text size.

Why Use rem for Font Sizes — Accessibility Matters

Sizing type in rem instead of px is a meaningful accessibility improvement. When a visitor increases their browser's default text size (a common need for users with visual impairments or those reading on high-DPI screens), every rem-based font size and spacing value scales with it proportionally. px values stay fixed and can produce layouts where text becomes too small relative to its container.

WCAG 2.1 Guideline 1.4.4 requires text to be resizable up to 200% without loss of content or functionality. Building with rem units by default makes meeting this guideline much easier — your entire typographic scale and much of your spacing shifts when the root changes, keeping proportions intact. This is why tools like Tailwind CSS default to rem units throughout.

Common px to rem Values — Quick Reference

At the standard 16px root: 8px = 0.5rem, 10px = 0.625rem, 12px = 0.75rem, 13px = 0.8125rem, 14px = 0.875rem, 16px = 1rem, 18px = 1.125rem, 20px = 1.25rem, 24px = 1.5rem, 28px = 1.75rem, 32px = 2rem, 36px = 2.25rem, 40px = 2.5rem, 48px = 3rem, 64px = 4rem.

These are the values you'll type most often in a CSS codebase. The reference table in the tool lists all of these and lets you copy any value with a single click — faster than calculating manually every time and less error-prone than memorizing the table. Bookmark this rem calculator and open it whenever you need to translate between a design spec in pixels and CSS in rem units.

Private, Instant and Free — No Signup Required

There's nothing to install and no sign-up. Every conversion — px to rem, rem to px, px to em, em to px — happens locally in your browser with JavaScript. The values you enter never leave your device and are never sent to any server. Unlike some online converters that require creating an account or watching ads before accessing results, everything here is available immediately and without restriction.

The tool works offline once loaded, has no usage limits, and works on any device — desktop, tablet, iPhone, or Android. Bookmark this px to rem converter as a daily-use CSS tool and save yourself from mental arithmetic every time you translate a Figma design spec into scalable CSS.

The Full CSS Unit Landscape

CSS offers two categories of length units: absolute units and relative units. The absolute set includes px, pt (points, 1pt = 1.333px), pc (picas, 1pc = 16px), and the physical units cm, mm, and in. Of these, only px is practically useful on screen — the others were designed for print and map to physical dimensions only when the output device reports an accurate DPI, which most monitors do not. A "1cm" rule on a 96 DPI monitor will not measure 1 centimeter with a ruler.

The relative set is where modern CSS lives. em scales with the font size of the element's direct parent. rem scales with the root html element's font size — one global anchor. % is relative to the parent element's equivalent property. The viewport units (vh, vw, vmin, vmax) relate to the browser viewport dimensions. ch equals the advance width of the "0" glyph in the current font — useful for setting a column to exactly N characters wide. ex is the x-height of the current font (roughly the height of a lowercase "x"), used occasionally for vertical rhythm.

Two newer additions deserve attention: dvh, svh, and lvh solve the notorious mobile "100vh too tall" bug (covered below), and the container query units cqi and cqb, introduced in 2023, are percentages of the nearest container's inline or block size. cqi and cqb unlock component-level responsive design that doesn't need to know anything about the viewport — a card can resize based on the column it's in, not the screen it's on.

Why rem Beats em for Font Sizing

em compounds through nested elements in a way that quickly becomes hard to reason about. If a Modal sets font-size to 1.25em, and a Card inside it sets font-size to 1.25em, and a label inside that Card sets font-size to 1.25em, the label renders at 1.25 × 1.25 × 1.25 = 1.953× the base size — nearly double — with no obvious signal in the code. Add another layer and it reaches 2.44×. This compounding effect is one of the oldest gotchas in CSS, responsible for countless "why is my nested text so huge?" debugging sessions.

rem eliminates compounding entirely by always anchoring to the root html element. A label set to 1.25rem inside a Card inside a Modal inside a Dialog always renders at exactly 1.25× the root font size, regardless of how many ancestors set their own font-size. This predictability is why every major component library — including Material UI, Chakra, Radix, and Mantine — defaults to rem for typography and spacing tokens.

The practical consequence is significant for design systems: when you compose components, rem-based sizes stay consistent while em-based sizes require authors to mentally track the entire ancestor chain to know what the rendered size will be. Reserve em for intentional relative scaling — for example, an icon that should be 1.2em so it scales with whatever font size its sibling text uses — rather than as a general font-size unit.

The 62.5% Root Font-Size Trick — Popular but Controversial

The 62.5% trick sets html { font-size: 62.5%; }, which at the browser default of 16px evaluates to 10px. This makes rem arithmetic trivially simple: 1.6rem = 16px, 2.4rem = 24px, 3.2rem = 32px. Every rem value is just the pixel value divided by 10, which many developers find easier to read and write than dividing by 16 (which rarely produces round numbers — 14px becomes the opaque 0.875rem).

The problem is that it overrides the user's browser font-size preference. When a user sets their browser default to 20px for readability — a common need for users with low vision, or anyone reading on a large screen from a distance — html { font-size: 62.5%; } makes 62.5% of 20px = 12.5px the new root. Every rem value on the site now anchors to 12.5px instead of the user's intended 20px. Any rem-based font size is now smaller than the user needs, not larger. The technique defeats the entire accessibility benefit of using rem in the first place.

WCAG 2.1 Success Criterion 1.4.4 (Resize Text, Level AA) requires that text can be resized up to 200% without loss of content or functionality. The 62.5% trick doesn't violate this directly if you only use it for the math shortcut, but it substantially erodes the user font-size respect that rem is supposed to provide. A cleaner approach is to keep the root at its default (or at a percentage like 100% that explicitly defers to the user setting) and accept that 0.875rem is just the way you write 14px. The converter here can help you build intuition for the 16-base values so the mental division becomes second nature.

When px Is the Right Choice

Despite the strong case for rem, some CSS properties belong in px. Border widths are the clearest example: border: 1px solid should render as exactly one device pixel — a crisp, hairline rule. If you wrote border: 0.0625rem solid (which is 1px at 16px root), it would grow proportionally when a user increases their root font size, turning your 1px decorative border into a 1.25px or 1.5px line that may look heavy or blurry on subpixel boundaries. Box shadows and outlines have similar characteristics — their blur radius and spread are often aesthetic choices that should stay constant.

Media query breakpoints in px are a deliberate choice in most frameworks, though the debate is live. Using rem in media queries means a user who sets their browser default to 20px will hit your "768px breakpoint" at 768 × (20/16) = 960px of actual viewport width — their narrow layout triggers later than intended. Some teams treat this as a feature (the layout responds to the user's effective content width), others as a footgun. Tailwind CSS uses px breakpoints; frameworks aimed at maximum accessibility sometimes use rem breakpoints. Know which behaviour you want before you decide.

Images with known pixel dimensions, SVG icons that must be pixel-precise, and elements whose size is coupled to a fixed-resolution asset (a 32×32 favicon embedded in the page, a sprite sheet) are all good candidates for px. The rule of thumb: use px when you're describing something that exists in device pixels (a border, a pixel-art graphic, a known-dimension photo) and rem when you're describing something that should scale with the reading context (text, whitespace, layout gaps).

Viewport Units Deep-Dive: vh, vw, dvh and the Mobile Bug

The viewport units vh and vw are percentages of the browser viewport's height and width respectively — 100vh means "the full height of the browser window." On desktop this works as expected, but on mobile browsers it caused one of the most widespread layout bugs in CSS history: mobile browsers include the address bar and bottom navigation chrome in their 100vh calculation. A hero section set to 100vh would extend behind the browser UI, getting clipped or causing a scroll offset on first load. The address bar hides when the user scrolls, which then changes the available height mid-session.

The 2022 solution was three new units: svh (small viewport height — viewport height when the browser chrome is fully visible, the smallest available space), lvh (large viewport height — height when chrome is fully retracted, the most space ever available), and dvh (dynamic viewport height — updates in real time as the chrome shows or hides). For full-height sections, min-height: 100dvh is now the correct modern answer. All three units are supported in Chrome 108+, Safari 15.4+, Firefox 101+, and Edge 108+, making them safe for production use.

vw has its own quirk on Windows: it includes the width of the vertical scrollbar in its calculation. On a page with a visible scrollbar, width: 100vw will extend slightly beyond the content area and create horizontal overflow. The fix is to use width: 100% on block elements (which naturally excludes the scrollbar) and reserve vw for cases where you genuinely need viewport-width reference independent of the document — large typographic headings that should track screen width, for example, with a formula like font-size: clamp(1.5rem, 5vw, 4rem) that combines rem floor/ceiling with a fluid vw middle.