4 lines of CSS everyone copies — and no one ever checked

/* Make text look crisper and more legible in all browsers */
body {
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  font-smoothing: antialiased;
  text-rendering: optimizeLegibility;
}

Source: Finsweet Client-First

If you work with Webflow, chances are you’ve pasted this snippet. And probably never asked questions. That makes sense — the source is authoritative, the comment sounds convincing. People drag this code from project to project without checking.

I got curious — what here actually works? And is it really “in all browsers”, like the comment promises? Spoiler: no.

What is Finsweet Client-First

Client-First is a set of guidelines and strategies for organizing and maintaining Webflow projects. One of the most popular frameworks in the Webflow community. It includes a ready-to-use “Global Styles Embed” — code that gets pasted into every project and ships with the Client-First starter template.¹

The snippet above is part of that embed, from the “Text clarity” section.

Precisely because the source is treated as a best practice, this code almost never gets questioned. People take it as is — and it lives in projects for years. Most likely no one ever validated it, which is why the snippet doesn’t get updated.

Line by line

-webkit-font-smoothing: antialiased — ✅ works, but only on macOS

-webkit- is a vendor prefix for the WebKit engine. It signals that the property is non-standard: implemented by browsers on their own, without a W3C spec. There’s no unprefixed version — and there won’t be one until the property gets standardized.

Visually, text becomes thinner and lighter, closer to how it looks in Figma. The property switches font smoothing from subpixel to grayscale antialiasing.

Works exclusively on macOS: Safari, Chrome, Edge, Firefox 128+. On Windows, Linux, and even iOS Safari — no effect, the browser just ignores it.²³

Important context: starting with macOS Mojave (2018), Apple disabled subpixel antialiasing at the system level. Browsers still use it by default — which is why -webkit-font-smoothing: antialiased brings web rendering in line with the rest of macOS.³

Keep it? Yes. But understand it’s macOS-only, not “all browsers.”

-moz-osx-font-smoothing: grayscale — ✅ works, redundant since 2024

A Firefox-specific («-moz» — mozilla) alias for the same behavior. Introduced in Firefox 25 (2013) as a deliberately limited property — the “osx” in the name signals the platform binding.

In July 2024, Firefox 128 shipped native support for -webkit-font-smoothing. From that point on, -moz-osx-font-smoothing effectively duplicates the first line for Firefox on macOS.⁴⁵

Keep it? Yes, for backward compatibility. If you don’t need to support Firefox versions before July 2024 — you can drop it.

font-smoothing: antialiased — ❌ dead code

This line does nothing. At all.

The font-smoothing property (with “-ing”) never existed in any W3C CSS spec. The 2002 CSS3 Fonts draft included a different property — font-smooth (without “-ing”), with different syntax and values. But it never made it to a recommendation.⁶

No browser — Chrome, Safari, Firefox, Edge — recognizes this property. The line gets parsed and silently ignored. You can check for yourself: the W3C CSS Validator throws an error — “Property font-smoothing doesn’t exist.”

A common misconception is that this is “the unprefixed version for the future.” But font-smoothing doesn’t exist in any spec — check it yourself on MDN.⁷

Keep it? No. Delete it.

text-rendering: optimizeLegibility — ⚠️ works, but dangerous on body

This is an SVG property that browsers also support for HTML elements. It enables kerning (precise spacing between letters) and ligatures (special letter combinations like fi, fl) — making text look more typographically accurate.

The problem: when applied to the entire body, it affects every piece of text on the page. And there are real, documented bugs in Chromium — text becomes invisible when combined with <video>, spaces between words disappear, text overflows its container.⁸⁹

MDN states it directly: not recommended for typical articles due to potential performance impacts. Best suited for large, short headings.¹⁰

One more thing: modern browsers already enable kerning and ligatures by default. In practice, the difference from adding optimizeLegibility to body is minimal — and the risks are real. If you explicitly need kerning, there’s a standard CSS alternative without side effects: font-kerning: normal (a standard property from the CSS Fonts Module, supported in Chrome 33+, Firefox 32+, Safari 9+).

Keep it? Not on body. Apply selectively — on headings only.

The bottom line: what you actually need in 2026

Out of four lines — two work, one is dead, one is potentially harmful when applied to body. The “in all browsers” comment doesn’t match reality for any of them.

Optimized version:

/* Font smoothing — macOS only */
body {
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}

/* Kerning & ligatures — headings only */
h1,
h2,
h3,
h4,
h5,
h6 {
  text-rendering: optimizeLegibility;
}

This isn’t a knock on Finsweet. Client-First is a useful methodology, and the snippet got there for a reason. It’s just that every “best practice” has a date of birth. And sometimes it’s worth checking it.