Summarize this article with AI
The CSS unit rem (root em) is relative to the font size of the root html element, which defaults to 16px in all browsers. It provides a consistent and predictable foundation for typography and spacing, unlike px (fixed, ignores user preferences) and em (relative to parent, subject to cascading effects). Using rem for font sizes, margins, and paddings creates a responsive design that automatically adapts to browser accessibility preferences. In Webflow, rem is natively available in the Designer and forms the foundation of the Client-First methodology. This article covers the definition, the rem/px/em comparison, conversion, how to use rem in Webflow, and the mistakes to avoid.
If you work on a Webflow site or collaborate with a front-end developer, you have probably come across the "rem" unit in CSS files or in the Designer. It shows up in font sizes, margins, paddings, and increasingly replaces pixels in professional projects. Yet many designers and marketing leads do not know exactly what rem means, or why developers insist on using it instead of pixels.
The short answer: rem stands for "root em." It is a CSS unit based on the font size of the root html element, which is set to 16px by default in all browsers. When a developer writes font-size: 1.5rem, it equals 24px (1.5 × 16). The key benefit is that all rem values share the same reference point, which makes the design consistent, maintainable, and accessible.
This article explains in detail what rem is, why it has become an essential best practice for developers, how it compares to pixels and em, how to use it concretely in Webflow, and which mistakes to avoid in order to get the most out of it.
What is the rem unit in CSS?
REM stands for "root em." It is a CSS unit whose value is calculated relative to the font size of the root element of the document, which is the <html> tag. By default, all modern browsers set the root font size to 16px. This means 1rem = 16px, 2rem = 32px, 0.5rem = 8px, and so on. The formula is always the same: the rem value multiplied by the root size gives the result in pixels.
What makes rem particularly useful is that this reference point is unique and stable. Unlike the em unit, which is calculated relative to the parent element (and whose value can therefore vary depending on the nesting level in the HTML), rem always points to the same source: the root. No matter whether the element is nested inside three or ten containers, 1.5rem will always produce exactly the same result. This predictability is the main reason front-end developers prefer rem over em for global sizing.
Here is a minimal example that illustrates how it works:
/* The root keeps the browser's default value */html { font-size: 100%; /* = 16px by default */}/* All rem values refer to this root */h1 { font-size: 2rem; /* = 32px */}p { font-size: 1rem; /* = 16px */ margin-bottom: 1.5rem; /* = 24px */}Browser support is universal. The rem unit is supported by all modern browsers, including mobile versions, and compatibility goes back to IE9. There is no technical reason not to adopt it in 2026.
Why developers use rem (and not pixels)
Pixels are intuitive. 16px is clear, precise, and you know exactly what you get. So why do professional developers recommend using rem for typography and spacing instead of pixels? The answer comes down to three concrete reasons that directly impact the quality of a website.
The first reason is accessibility. When a user changes the default font size in their browser (which is common among visually impaired users or people with reading difficulties), elements sized in rem adapt automatically and proportionally. A paragraph set to 1rem will go from 16px to 20px if the user has configured their default size to 20px. With pixels, nothing changes: the text stays locked at the value chosen by the developer, and the user loses the ability to adjust the display to their needs. The WCAG, the international web accessibility guidelines, explicitly require that text resizing should not be blocked. Using rem meets this requirement natively, without any extra effort.
The second reason is maintainability. When all font sizes, margins, and paddings on a site are expressed in rem, they share the same reference point. If the team decides to adjust the global typographic scale, changing the root size (via a media query, for example) will adjust the entire design proportionally without touching each value individually. With pixels, each value would need to be modified one by one, which is tedious on a 30-page site and a frequent source of inconsistencies. On medium to large projects, this difference translates into concrete time savings on maintenance and design evolution.
The third reason is design system consistency. Modern methodologies like Client-First (Finsweet) and other structured class systems use rem as the base unit for their entire spacing and typography system, with standardized increments (0.5rem, 1rem, 1.5rem, 2rem, etc.). A site built in rem with consistent values is easier for another provider to pick up, more readable for a developer joining the project mid-stream, and simpler to evolve over time. It is an investment in structure that reduces long-term maintenance costs.
REM vs px vs em: understanding the differences
To choose the right unit in the right place, you need to understand what each one does and where it excels.
The px unit is absolute. 16px stays 16px regardless of the user's preferences, the nesting level in the HTML, or the screen size. This rigidity is an advantage for elements that need to maintain a fixed dimension: thin borders (1px, 2px), box shadows, decorative icons, and visual details that should not change with the text size. However, using px for typography or spacing prevents the design from adapting to user preferences and different display contexts.
The em unit is relative to the parent element. If a container has a font-size of 18px, then 1em inside that container equals 18px. This is useful for creating self-proportioning components, like a button whose padding adapts automatically when its text size changes. The problem appears with nesting: each level multiplies the value. A font-size of 1.2em in an element nested three levels deep gives 1.2 × 1.2 × 1.2 = 1.728em, a result that is hard to predict and debug. This is why em is recommended only for local adjustments within isolated components, not for structuring the overall design.
The rem unit is relative to the root html element, and therefore constant throughout the entire document. 1.5rem always gives the same result, whether the element is at the first level of the DOM or nested inside ten containers. This predictability makes it the default choice for everything that visually structures a page: typography, margins, paddings, and spacing between sections.
The rule of thumb that front-end developers agree on: rem for typography and spacing, px for borders and shadows, % for fluid widths, and vh/vw for full-screen layouts.
How to convert px to rem
The formula is straightforward: rem value = desired pixels ÷ root font size. With the default base of 16px, this gives for example 24px ÷ 16 = 1.5rem. Once you understand the logic, the conversion becomes second nature. The most common values end up being memorized quickly, and a reference table covers everything else in seconds.
A popular technique is to set html { font-size: 62.5% } to get 1rem = 10px and simplify mental math (2.4rem = 24px, 1.6rem = 16px). This approach has a real readability advantage, but it comes with an important risk. By reducing the base size to 10px, it forces you to explicitly redefine every font size on the site. If a third-party component or an element is not redefined, it will inherit the reduced size and the result will be unreadable. Some front-end experts advise against this technique for this reason, and we share that view.
The safest recommendation is to keep html { font-size: 100% } (which defaults to 16px) and work directly with the corresponding rem values. It is more reliable for accessibility, it is the approach adopted by the majority of modern design systems, and it is also what the Client-First methodology recommends.
Using rem in Webflow: practical guide
Webflow uses px by default in the Designer, but switching to rem is simple and native. There is nothing to install or configure. To change the unit of any field (font-size, margin, padding, width, gap, etc.), simply click the unit dropdown next to the input field and select "rem." The rem unit is available for all numeric properties in the Designer, which means you can adopt it gradually or fully depending on the project's needs.
Webflow also offers a very useful shortcut for conversion. The Designer supports mathematical calculations directly in input fields. If you know the pixel value and want to convert it to rem, type for example 24/16rem in the field. Webflow will automatically calculate and display 1.5rem. This shortcut eliminates the need to check a conversion table every time and significantly speeds up the workflow when migrating an existing project from px to rem.
The Client-First methodology developed by Finsweet has made rem the cornerstone of its design system. All typographic sizes and spacing values are defined in rem, using standardized increments: 0.5rem, 1rem, 1.5rem, 2rem, 2.5rem, 3rem, and so on. This structured approach makes the design system readable and predictable. When a new provider takes over a project built with Client-First, they immediately understand the spacing logic without needing additional documentation, which reduces onboarding time and the risk of inconsistencies.
A fundamental point to understand: Webflow natively respects the browser's font size when values are in rem. If a user has configured their default font size to 20px instead of 16px (which is common among visually impaired users), text set to 1rem will display at 20px on their screen. This is accessibility that works automatically, without any extra configuration, as long as no font-size in px has been set on the html element. This is an advantage that pixels simply cannot offer.
To start a new Webflow project in rem, the most effective method is to lay the foundations from the very beginning. Start by defining all typographic classes (h1 through h6, body text, captions, labels) in rem. Then move to paddings and margins for sections and components, also in rem. Borders and shadows can stay in px without any issue, since these elements do not need to adapt to user preferences. This approach integrates naturally into a structured Webflow site creation workflow and makes long-term maintenance considerably easier.
Going further: clamp() and fluid typography
The CSS function clamp() is the natural complement to rem for teams that want to take responsive design one step further. It allows you to create typography that adapts fluidly to the screen width without needing to define media queries for each breakpoint. The syntax takes three parameters: a minimum, a preferred value, and a maximum. The minimum and maximum bounds are typically expressed in rem, while the preferred value uses vw (viewport width) to create a progressive interpolation between the two.
/* Fluid typography: the heading adapts between 1.5rem and 3rem */
h2 {
font-size: clamp(1.5rem, 2.5vw, 3rem);
}
In this example, the heading will be at least 1.5rem (24px on a 16px base), at most 3rem (48px), and will adapt progressively between the two depending on the viewport width. The result is a smooth transition between sizes, without abrupt jumps from one breakpoint to the next, which produces a much more natural and polished result than the usual discrete size changes.
A note for Webflow users: clamp() is not yet supported natively in the Designer. To use it, you need to go through custom code via an HTML embed or a <style> tag in the project head. If your project already uses custom code for GSAP animations for example, adding clamp() within the same workflow does not represent significant extra effort. The two approaches combine well and the code remains simple to maintain.
Common mistakes with rem (and how to avoid them)
Several mistakes come up regularly in projects that adopt rem. Some of them can completely cancel out the expected benefits, which is all the more frustrating because they are easy to avoid once identified.
The most problematic is setting a font-size in px on the html element. Writing html { font-size: 16px } seems harmless, but this declaration cancels the main benefit of rem. If the user has configured their default size to 20px in their browser, this line of code forces it to 16px and accessibility is lost. The best practice is to always keep html { font-size: 100% } or not to define any font-size on html at all, which lets the browser use its default value and preserves the link between rem and user preferences.
The second mistake is using rem values with long decimals that make the code difficult to read and maintain. A padding of 1.4375rem (23px) is technically correct, but when the CSS file contains dozens of values like this, maintenance becomes painful and errors multiply. It is better to round to standardized values (1.5rem for 24px rather than 1.4375rem for 23px) or use the increments defined by the project's design system. Consistency matters more than pixel-level precision.
The third mistake is mixing px and rem without a clear logic. If headings are in rem, body text is in px, and margins are in em, maintenance becomes complex and responsive behavior unpredictable. The rule is simple: choose rem as the default unit for everything related to typography and spacing, and reserve px only for elements that must remain fixed, such as borders, shadows, and decorative details. This convention should be shared with the entire team from the start of the project.
The fourth mistake is forgetting to test with different browser font sizes. Many designers test only with the default 16px and consider the job done. To verify that the design adapts correctly in rem, you need to change the font size in the browser settings (20px, 24px) and observe the result. It is during these tests that overflows, overlapping elements, and layout issues surface. Fixing them upfront is much simpler than after going live.
Finally, using rem for borders is a common but unnecessary mistake. A 1px border should stay at 1px regardless of the text size. Defining it in rem would make it grow proportionally when the user increases their font size, which produces a visually inconsistent result and provides no accessibility benefit whatsoever.
Checklist: switching a Webflow project to rem
- Verify that the html element does not have a font-size set in px. If it does, replace it with
font-size: 100%or remove it entirely to let the browser use its default value. - Define all typographic classes (h1 through h6, body text, captions, labels) in rem from the start of the project, before beginning content integration.
- Convert section and component margins and paddings to rem. Use the Webflow shortcut
value/16remin input fields to convert quickly from pixels. - Keep borders, box shadows, and decorative details in px, since these elements need to maintain a fixed size regardless of user preferences.
- Use standardized, readable rem values: 0.5, 0.75, 1, 1.25, 1.5, 2, 2.5, 3, 4. Avoid long decimals like 1.4375rem that make the code difficult to maintain.
- Test the design with at least three different browser font sizes (16px, 20px, 24px) to verify responsive behavior and detect potential overflows.
- Check accessibility: browser zoom at 200% should not cause overlapping elements or clipped content.
- Document the rem values used in the project (px/rem correspondence table) so that every contributor can maintain design system consistency.
- If the project follows the Client-First methodology, align rem values with the standardized increments (0.5rem, 1rem, 1.5rem, 2rem, etc.) to ensure compatibility with the Finsweet ecosystem.
- Before going live, run a full check on mobile, tablet, and desktop to confirm that rem-based spacing behaves correctly across all breakpoints.
Conclusion
Rem is the reference CSS unit for building a responsive and accessible design. It provides a single reference point through the root element, consistency across the entire site, and automatic respect for user preferences. In Webflow, adopting it is simple, native, and compatible with professional methodologies like Client-First. These are the reasons front-end developers systematically recommend it for typography and spacing.
The starting point is concrete: switch typographic classes and spacing to rem, keep px for borders and shadows, test with different browser font sizes, and document the values used. These few changes are enough to significantly improve the responsive quality and accessibility of a project.
If you are launching a Webflow project and want to start on solid foundations with a structured design system, clean responsive behavior, and accessibility built in from day one, you can get in touch with our team for an initial conversation about your project.












