CSS Em/Rem/PX Converter

About this tool

px ↔ rem ↔ em ↔ pt

Convert CSS units: pixels, ems, rems, and points. Single value mode + batch table mode for building design system reference sheets. Configurable root + parent font sizes.

RT-DEV-082 · Developer Tools

🎯 Single conversion

Value

Unit

Root font-size (px)

Parent font-size (px, for em only)

Pixels

—

Rem

—

Points

—

📋 Batch table (for design system reference)

Start (px)

End (px)

Step (px)

Pixels	Rem	Points	Visual

How to use the CSS Unit Converter

Single conversion mode

Type any value and pick its unit — all four units are computed instantly. Default root font-size is 16px (the browser default). If your CSS resets html { font-size } to something else, update the "Root font-size" field to match. For em conversions, set the "Parent font-size" too — em is relative to the immediate parent's computed font-size, not the root.

Batch table for design systems

The batch table generates px → rem → pt rows in regular increments. Useful for building design system documentation, picking sizes from a standardised set, or converting existing px-based stylesheets to rem-based. Adjust start, end, and step to match your design grid (8px-step grid is most common; 4px-step for tighter systems).

Use rem for typography, px for borders

Best practice: font sizes, line heights, and paragraph spacing in rem (responds to user browser settings — accessibility win). Borders, fixed UI heights, decorative elements in px (don't need to scale with text size). Em for component-internal sizing (e.g. button padding = 0.5em → automatically scales with button's font-size). This hybrid gives accessibility benefits where they matter without losing pixel-perfect control where it counts.

Beware the 62.5% trick

An old hack sets html { font-size: 62.5% } so 1rem = 10px (easier mental math). The trick has fallen out of favour because it BREAKS the user's font-size preference scaling (your "10px base" overrides their 20px preference, defeating the accessibility benefit). Modern recommendation: keep html font-size at 100% (16px default), use rem directly, embrace decimals (1.125rem instead of 11.25px). Type scale tokens are the better solution.

CSS units — when to use px, em, rem, pt, and friends

CSS has more length units than any reasonable developer needs to know, but four units cover 95% of real work: px (absolute pixels), rem (relative to root font-size), em (relative to parent font-size), and pt (typographic points, rare in web but common in print stylesheets). The choice matters because each unit has different scaling behaviour, especially with respect to user font-size preferences in the browser. Picking the right unit per use case is one of those skills that quietly distinguishes good frontend developers from great ones.

Why rem beats px for typography

The strongest argument for rem-based typography is accessibility. The browser's default font size is 16px, but users can change it in Settings — 18px, 20px, even 24px for users with low vision (about 10% of adults). Rem-based designs scale with that preference: a 1.25rem heading becomes 20px when default is 16px, 22.5px when default is 18px, 25px at 20px default. Pixel-based designs lock the heading at 20px regardless of user preference, defeating the accessibility benefit. The 2018 W3C BCP guidance recommends rem for font sizes; Material Design 3, Apple HIG, IBM Carbon, and Tailwind CSS defaults all follow this. For ASEAN-specific use: government accessibility regulations (Singapore IMDA, Malaysia MAMPU) increasingly mandate rem-based typography for compliance with WCAG 2.1.

Use rem for font sizes (accessibility wins). Use px for borders and fixed UI heights (precision wins). Use em for component-internal spacing (composability wins). The right unit depends on the use case.

The em / rem distinction matters more than you think

rem = relative to the ROOT element (html). 1rem always equals the html element's computed font-size (usually 16px). Consistent across the entire document. em = relative to the PARENT'S computed font-size. 1em inside a button with font-size: 14px equals 14px; the same 1em inside a button with font-size: 20px equals 20px. Em is component-aware — buttons sized in em automatically scale their internal spacing with their text. The classic em-heavy CSS pattern: button { font-size: 1rem; padding: 0.5em 1em; }. Resize the button by changing font-size; padding follows proportionally. This composability is powerful but requires care — nested elements multiply, leading to "em creep" where deep nesting produces unexpectedly large sizes.

The ASEAN frontend-development angle

Frontend development across ASEAN has matured significantly. Singapore: deep talent pool (Grab, Sea, Shopee, DBS, GovTech all have hundreds of frontend engineers); design systems are universally rem-based for accessibility compliance. Indonesia: rapidly growing scene with Tokopedia, GoTo, Bukalapak, Traveloka leading on engineering practices. Vietnam / Philippines: large outsourcing centers (Globant, KMS, OnDemand) build EU/US client projects to accessibility standards. Thailand: smaller but skilled scene around True Digital, AIS, Central Pattana. Across the region, the technical choice is increasingly clear: rem for typography is industry standard. Even pixel-perfect designers from Figma/Sketch backgrounds learn the rem conversion because their designs ship in rem. The mental shift from "16px equals 1rem" to "1rem equals my user's preferred reading size" is the key accessibility insight.

10 Things to Know About CSS Units

1rem = html element's computed font-size. Defaults to 16px. Changes globally when user adjusts browser font preference.

1em = parent element's computed font-size. Composable: changing a component's font-size scales all its em-based sizes proportionally.

1pt = 1.333px (web). 1pt = 1/72 inch; 1px = 1/96 inch (CSS reference pixel). Conversion is exact.

The "62.5% trick" (html { font-size: 62.5% }) was popular for making 1rem = 10px. Now considered anti-pattern — breaks user font preference scaling.

Modern best practice: rem for typography, px for borders, em for component-internal spacing. Hybrid approach combines accessibility + precision.

About 10% of adults adjust their browser font size for readability. Rem-based designs scale with their preference; px-based don't.

CSS Tailwind uses rem-based defaults: text-base = 1rem (16px), text-lg = 1.125rem (18px), etc. Multi-platform-friendly.

vw / vh units (viewport-relative) work for responsive design: 1vw = 1% of viewport width. Combined with clamp() for fluid typography.

The CSS "reference pixel" is 1/96 inch — not actually a physical pixel. On high-DPI screens, 1 CSS px = 2+ physical pixels.

Print stylesheets often use pt (typographic points) for compatibility with print conventions. Web stylesheets rarely need pt.

Frequently Asked Questions

Rem is always relative to the ROOT element (html) — usually 16px. Consistent across the document. Em is relative to the PARENT element's computed font-size — changes based on context. Example: a div with font-size: 20px contains a button with padding: 1em. That 1em = 20px (parent's font-size). The same button outside the div would use the root font-size. Rem is predictable; em is composable. Use rem for top-level sizes (typography); em for component-internal spacing that should scale with the component.
Yes — for accessibility. ~10% of adults adjust their browser default font size for readability (usually due to vision). Rem-based typography scales with that preference; pixel-based ignores it. The W3C BCP guidance, WCAG 2.1, and modern design systems (Material 3, Apple HIG, IBM Carbon) all recommend rem. Exception: pixel-based is fine when the design INTENTIONALLY should NOT scale with user preference — typically only for fixed-size UI chrome elements where text scaling would break the layout.
No. The "html { font-size: 62.5% }" hack was popular for making 1rem = 10px (easier mental math: 1.6rem = 16px, 2rem = 20px). It's now considered an anti-pattern because it BREAKS user font preference scaling — if a user sets their browser to 20px default, your 62.5% (12.5px) overrides their preference and ships them text at 12.5px regardless of their accessibility need. Modern recommendation: keep html font-size at 100%, use rem directly (1.5rem = 24px, 1.125rem = 18px), embrace the decimals.
Real problem with deeply-nested em-based sizing. Each level multiplies:

... = 1.32em at the leaf, not 1em. Mitigation: use em sparingly for component-internal sizing; switch to rem at component boundaries. Or use design tokens / utility classes that apply specific rem-based sizes at each level. Modern frameworks (Tailwind, Vanilla Extract) prefer utility classes over em-based nesting for this reason.
1pt = 1/72 inch (typographic convention). 1 CSS px = 1/96 inch (web convention). So 1pt = 96/72 = 1.333px exactly. Points are common in print stylesheets (because print readers use traditional typography) and historically in Mac OS UI. Web designers rarely need pt — use px for fixed UI sizes, rem for typography. The pt column in this calculator's batch table is mostly for print stylesheet preparation.
Viewport-relative units. 1vw = 1% of viewport width; 1vh = 1% of viewport height; vmin = smaller of vw/vh; vmax = larger. Useful for fluid typography (clamp(1rem, 2vw + 0.5rem, 2rem) scales smoothly between sizes) and full-bleed sections (height: 100vh hero). On mobile, vh has the dynamic-toolbar issue — Safari + Chrome address bars resize the viewport. Use dvh (dynamic viewport height) for mobile-aware sizing. This calculator handles px/em/rem/pt; vw/vh are separate units for separate use cases.
They don't, directly. CSS pixels are abstract "reference pixels" (1/96 inch) — different from physical screen pixels. On a Retina display, 1 CSS px = 2-3 physical pixels (the OS scales). Your designs render the same visual size; the screen just uses more pixels to render them with higher fidelity. This is why the calculator's conversions are pure math — they don't care about device pixel ratio. Bitmaps DO care: a 100px wide JPG looks crisp on 1x screens, slightly soft on 2x, very soft on 3x — which is why you ship @2x and @3x versions of raster images.
Tailwind's defaults (text-base 1rem, text-lg 1.125rem, etc.) follow a Major Third (1.25) scale with sensible rem values. For most projects, use defaults — they're well-considered, accessibility-compliant, and consistent with other Tailwind users you'll inherit code from. For brand-specific design systems, override Tailwind's font-size scale with your own (use this calculator's Tailwind output to generate the config). For one-off projects, customizing is overkill; defaults are fine.
No. All calculations run entirely in your browser via JavaScript. There's no server roundtrip — open DevTools → Network and confirm zero outbound requests. Your values stay on your device. Safe for design system documentation, unannounced product work, or any frontend work that shouldn't leave your machine.
Niche but useful. 1ch = width of the "0" (zero) character in the current font (used for monospace column widths — try max-width: 65ch on prose for ideal line length). 1ex = approximate height of the lowercase "x" in the current font. Both are font-relative like em. Use ch for column widths in proportional fonts; ex is rarely useful. Not included in this calculator because their pixel equivalents depend on the specific font, which varies per element.