Understanding em vs px in CSS Breakpoints
In CSS media queries, both em and px units can be used to define breakpoints, but they behave differently. The key difference lies in how they scale — px represents absolute pixel values, while em is a relative unit based on the root font size. Using em allows for more flexible, scalable breakpoints that adjust when the base font size changes.
px breakpoints are fixed and remain constant regardless of the user’s font or zoom settings.
em breakpoints are relative to the root font size (usually 16px by default) and scale when the font size changes.
Using em makes designs more accessible and responsive to user zoom preferences.
px values are easier to reason about but less adaptable to dynamic or user-defined font scaling.
In this example, both breakpoints target the same width (768px), but the em version adapts if the root font size changes — for example, due to user accessibility settings or browser zoom levels. This makes em-based breakpoints more flexible for responsive, user-friendly design.
You're building a mobile-first card component and your designer gave you breakpoints at 320px, 768px, and 1024px. Your teammate says you should use 20em, 48em, and 64em instead. What’s the practical difference, and which one would you pick for this task?
If you set a media query to (min-width: 16em) but the root font size is 20px instead of 16px, what happens to your breakpoint? Show me how you’d debug that.
You’re told to make a button responsive at 500px, but your teammate used em for all other breakpoints. Should you match their unit? Why or why not?
Our mobile layout breaks on iPads because the breakpoints were defined in px, but users on high-DPI devices are seeing unexpected behavior. How would you investigate and fix this?
A feature works perfectly in our design system using px breakpoints, but accessibility testers say content overflows on high-zoom. What’s the root cause, and how would you adjust the breakpoints without breaking existing layouts?
We inherited a codebase with a mix of px and em breakpoints. One component looks fine on desktop but collapses on mobile. How do you diagnose whether it’s a unit mismatch or a logic error?
We’re redesigning our responsive grid system and debating whether to use em or px for breakpoints. What are the long-term tradeoffs in maintainability, accessibility, and cross-team consistency? How would you propose a standard?
Our design system uses em breakpoints for accessibility, but our analytics show 30% of users have custom font sizes. How do you balance accessibility goals with pixel-perfect design expectations across multiple product teams?
You’re migrating a legacy app from px to em breakpoints. What edge cases could break existing layouts? How would you test and validate the migration without introducing regressions?
Our company has 12 product teams using different breakpoint units across 50+ apps. We’re building a shared design system and need to enforce consistency. How do you design the policy, handle legacy debt, and get buy-in from teams resistant to change?
We’re scaling our UI framework globally and need breakpoints that work across languages with different default font sizes (e.g., Japanese vs English). Should we use em, rem, or something else? What’s your architecture decision and how do you justify it to engineering leadership?
A major accessibility audit found our breakpoints are unusable for users with low vision who rely on browser zoom. We’ve used px for years because ‘it’s precise.’ How do you lead a company-wide shift to accessible units without breaking critical revenue features?