Most CSS unit bugs aren't dramatic — a layout doesn't collapse, it just quietly behaves slightly wrong for some users, which is exactly why these mistakes survive in production for so long.
1. Hardcoding Font Sizes in PX
font-size: 16px looks harmless, but it ignores a user's browser accessibility setting for a larger default font size — pixel text stays frozen no matter what they've configured. Use rem for font sizes so they respect that preference.
The most damaging version of this mistake is on the root element, because it disables the preference for every rem value on the site at once:
/* Problem */
html { font-size: 16px; }
h1 { font-size: 32px; }
p { font-size: 16px; }
/* Fix */
html { font-size: 100%; } /* or leave it out entirely */
h1 { font-size: 2rem; } /* 32px at the default */
p { font-size: 1rem; } /* 16px at the default */At the default settings both versions look identical, which is exactly why this mistake survives code review. Divide each pixel value by 16 to get the rem equivalent, or use our PX to REM converter for a batch of values.
2. Forgetting the Viewport Meta Tag
Without <meta name="viewport" content="width=device-width, initial-scale=1.0"> in the page head, mobile browsers render the page at a fake desktop width (commonly around 980px) and shrink it down, making every other responsive CSS rule pointless. This one missing line breaks mobile layouts more often than any actual CSS mistake.
The opposite mistake is just as common: adding maximum-scale=1 or user-scalable=no to stop the page zooming. That blocks pinch-zoom for people who need to enlarge content, and some browsers now ignore it for that reason. Keep the tag to width=device-width, initial-scale=1. Our guide to the viewport in CSS explains how the layout viewport and visual viewport differ.
3. Using 100vh for Full-Screen Mobile Sections
On mobile Safari and Chrome, 100vh includes space hidden behind the browser's address bar, so a "full screen" section often runs taller than what's actually visible and cuts off content at the bottom. Pair it with a fallback: height: 100vh; height: 100dvh;
Modern browsers offer three viewport-height units, and each fits a different job:
| Unit | Measures | Good for |
|---|---|---|
svh | Small viewport: browser toolbars fully shown | Hero sections that must always fit on screen |
lvh | Large viewport: toolbars hidden (same as vh) | Backgrounds that may extend under the toolbar |
dvh | Dynamic: changes as toolbars show and hide | Full-screen app shells |
Be aware that dvh recalculates while the user scrolls, which can make content jump. For a section that should simply fit the screen, min-height: 100svh; is often the calmer choice. More detail is in our guide on how to use vh and vw in CSS.
4. Mixing EM and REM Without a Reason
Using em and rem interchangeably in the same component tree makes sizes hard to predict, since em compounds with nesting and rem doesn't. Pick rem as the default for typography and spacing, and use em only when a value should deliberately scale with the element's own font size (see our REM vs EM guide).
A classic symptom is a nested list where each level shrinks: li { font-size: 0.9em; } gives 14.4px at the first level, 12.96px at the second and about 11.7px at the third. Changing it to 0.9rem keeps every level at 14.4px.
5. Setting Breakpoints in EM/REM Inconsistently
Some teams write media queries in px, others in em, and mixing both across a codebase makes breakpoints behave inconsistently if the user's default font size is anything other than 16px — em breakpoints move, px breakpoints don't. Pick one convention for breakpoints project-wide and stick to it — most teams find px simplest here specifically because breakpoints are about device width, not typography.
A related bug is overlapping ranges. max-width: 768px and min-width: 768px both match at exactly 768px, so both rule sets apply at that width. Use the newer range syntax, which most current browsers support, to make the boundary explicit:
@media (width < 768px) { /* mobile */ }
@media (width >= 768px) { /* tablet and up */ }Bonus Mistakes Worth Checking
Using 100vw for full-width elements
width: 100vw includes the vertical scrollbar on desktop browsers that show classic scrollbars, so the element ends up wider than the visible area and causes a horizontal scrollbar. Use width: 100% on a block element instead.
Fixed heights on text containers
height: 40px on a button looks fine until the text is translated, wraps, or is enlarged by the user. Use min-height plus vertical padding so the box can grow.
Line-height with a unit
line-height: 24px or 1.5em is inherited as a fixed length, so a large heading inside gets cramped lines. A unitless line-height: 1.5 is recalculated for each element.
Expecting percentage padding to follow height
Vertical padding and margin in percent are calculated from the containing block's width, not its height. padding-top: 50% on a box inside a 600px-wide container is 300px. For aspect ratios, the aspect-ratio property is clearer.
Quick Audit Checklist
| Search your CSS for | What to check |
|---|---|
html { font-size: …px } | Replace with a percentage or remove |
font-size: …px | Convert to rem |
100vh | Add an svh or dvh value |
100vw | Usually replace with 100% |
height: on buttons and badges | Switch to min-height |
user-scalable=no | Remove from the viewport tag |
The Common Thread
Almost every one of these mistakes comes down to the same root cause: treating an absolute unit (px) as if it were relative, or vice versa. Knowing which of your values should track the user's settings and which should stay fixed prevents most of this category of bug before it ships. If you want a simple rule for that decision, our PX vs REM guide lays it out property by property.
Frequently Asked Questions
How can I find px font sizes quickly in a large project?
Search the codebase for font-size: followed by a number and px. A stylelint rule such as unit-disallowed-list scoped to the font-size property can also stop new ones being added.
Is it a mistake to use px for borders?
No. Borders, shadows and outlines are decorative and generally should not grow with text. Px is the right unit for them.
Will fixing these mistakes change my design?
At the default 16px font size, converting px to rem produces identical results. The changes only show up for users with different settings, or on devices where viewport units were previously miscalculated.
Do these mistakes affect search rankings?
Indirectly. A missing viewport tag makes a page hard to use on mobile, and mobile usability matters for how a page performs. Most of the other issues mainly affect accessibility and user experience.
Try It Yourself
Double-check your own conversions with our CSS unit converters, or fix up your color values with our Color Converter.