PX to EM Converter
px to em converter px to em/rem reference provides conversion math for typography handoff, recommen px to em rem conversion
Introduction
px to em rem conversion for HTML typography bridges designer specs and relative scaling in user stylesheet — base font-size on html element anchors rem; em compounds nested and breaks predictability in component HTML. Staff engineers document typography tokens in rem, use px only for hairlines, and set meta viewport for mobile scaling.
Business problem
Business pressure: Inline style font-size:14px in CMS HTML blocks user zoom preferences; em nesting in email templates compounds unpredictably across clients.
- A11y: WCAG 1.4.4 resize text 200% — px-only layouts break
- Consistency: Mixed px/em in HTML fragments breaks DS scale rhythm
- Maintenance: Rebrand 16px→18px base requires manual grep without rem tokens.
Why this feature exists
Platform motivation: Relative units scale with user preferences; rem references root for predictable component math.
- History: em from metal type width; ex ch units for measure
- Alternative rejected: px everywhere — fights user agent defaults
- Modern role: clamp() fluid type in CSS; HTML style attr still uses px in email
Browser internals
Computed values: Browser converts relative units to px for layout; default root 16px typically; user stylesheet can change base.
- Parser: style attribute values parsed as CSS declarations
- DOM: getComputedStyle returns px even if specified rem
- Script impact: matchMedia and resizeObserver use px layout values
Rendering workflow
Text scaling reflow: rem-based text in HTML+CSS reflows on root change; px inline in HTML email may not respect user zoom same way web.
- Critical path: Web font size affects LCP text paint timing slightly
- Layout: em padding nesting explodes — prefer rem in component roots
- Paint: Subpixel text positioning differs px vs rem rounding
Feature deep dive
Conversion: em = px / parent font-size; rem = px / root font-size (default 16); formula table: 12px=0.75rem, 14px=0.875rem, 16px=1rem, 18px=1.125rem, 24px=1.5rem at 16px root.
- html { font-size: 100%; } respects user default — avoid 62.5% hack in new work
- Inline HTML: Prefer class over style="font-size:14px".
- Email: px still dominant — document exception.
<!-- Web: class not inline px --><html lang="en" style="font-size:100%"><!-- DS token .text-sm { font-size: 0.875rem; } --><p class="text-sm">Body copy at 14px equivalent when root 16px</p>
Accessibility analysis
A11y scaling: Users increase default font — rem layouts adapt; check 200% zoom no horizontal scroll; avoid px heights on text containers in HTML.
- Screen readers: Independent of unit — structure matters
- Keyboard: N/A units
- WCAG: 1.4.4 resize text; 1.4.12 text spacing
SEO impact
SEO: Negligible; readability affects engagement indirectly.
- Crawl: N/A
- Rich results: N/A
- Core Web Vitals: Text as LCP — legible size helps UX not metric formula
Security considerations
Low risk: style attr injection with font-size — sanitize in UGC; no direct XSS via units alone.
- XSS: style attr still injection vector for exfil tricks in old browsers — CSP style-src
- CSP: Restrict inline style where possible
- Phishing: Tiny px text hiding terms — unethical pattern lint in legal HTML templates
Performance impact
Perf: Negligible; fluid clamp reduces breakpoint-specific HTML duplication.
- LCP: Large root font small change to text LCP paint
- INP: N/A
- CLS: Fixed px containers clip scaled text — cause CLS or overflow
Real production example
Token table: DS JSON maps text-sm to 0.875rem; build tool rejects px in author HTML lint.
Enterprise usage
Enterprise: Typography ADR: rem in web HTML classes; px allowed list in email template path only.
- Design system: Figma px export script converts to rem tokens
- CMS: Strip inline font-size px from pasted Word HTML
- CI gates: Stylelint rem preferred in stylesheets tied to HTML templates
Common production failures
What breaks in prod: 62.5% root hack + em nesting — component font sizes wrong after DS merge.
- Incident: Legal disclaimer 10px inline — unreadable zoom failure audit finding
- SEO regression: N/A
- Perf regression: N/A
Architecture review questions
- Are font sizes in rem via classes not scattered px inline?
- Is root font-size 100% not arbitrary px on html?
- Does 200% zoom reflow without loss of content?
- Is px-to-rem conversion table documented for handoff?
- Are email templates exception documented separately?
Hands-on project
Project: Convert sample HTML with px inline styles to rem class-based tokens; test 200% browser zoom.
- Deliverable: before/after HTML + conversion table doc.
- Verify: No horizontal scroll at 200% zoom AA pages
- Stretch: clamp() fluid heading one h1
Interview questions
When do you use px vs rem vs em in HTML/CSS systems?(Advanced)
rem for component typography and spacing scale — predictable vs root; em for media queries relative to component or padding proportional to element font; px for borders hairlines and email HTML where rem poorly supported; set html font-size 100% respect user; avoid em nesting font-size hell.
Follow-up: 62.5% root hack still?
How does px to em conversion relate to accessibility?(Advanced)
Users scale default font — rem layouts grow; fixed px small text fails WCAG resize requirements; test 200% zoom; avoid locking containers in px heights; relative units support user agent preferences and browser text sizing settings.
Follow-up: ch unit for measure?
How do enterprises enforce typography units in HTML from CMS?(Advanced)
Strip inline font styles on paste; class-only typography tokens in rem; lint px in HTML style attrs; separate email pipeline px table; Figma-to-token automation; document conversion reference for authors not manual math.
Follow-up: viewport meta interaction?
Try it yourself
Edit the HTML, CSS, or JS panels — the preview updates as you type.
Try it yourself
Summary
PX to em/rem reference provides conversion math for typography handoff, recommends rem design tokens over inline px in HTML, and documents email px exceptions with accessibility scaling requirements.