Correcting Subpixel on Web
Most typefaces fail on web after the design hits production. The browser loads your font and then makes its own rendering decisions, and those automatic decisions are almost always the wrong ones.
By default, browsers use subpixel antialiasing. This makes text render heavier than intended, slightly blurry, and inconsistent with what you designed in Figma. But it is fixable with just four lines of CSS.
CSS
* {
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
}
Figma Lies
The way a typeface renders on screen has nothing to do with which typeface you chose. It has to do with how the browser rasterizes the letterforms onto the pixel grid.
The same font at the same size and weight can look noticeably different depending on the OS and display, because each platform has its own rendering pipeline and antialiasing method.
Figma has none of this. It uses its own renderer which is consistent across every machine you open it on, which means what you see in the design file is not what ships.
You can override these defaults in CSS, but most projects never do, so the font lands in whatever rendering pipeline the platform has set up and the output is whatever comes out.
Antialising OFF
Antialising ON
Why It Exists
Subpixel was a clever solution to a real problem. On low-DPI screens, each pixel is large enough to be visible, so rendering letterforms cleanly onto that grid requires some trickery.
The browser would use the individual RGB components of each pixel to simulate a finer grid than the display actually had. The result was sharper-looking text on hardware that could not physically deliver it.
The problem is that most screens today are high-DPI or Retina display, and pixels are small enough that the subpixel trick not only becomes unnecessary, it's actually a bad approach as the text ends up heavier, slightly blurred, and nothing like what you designed in Figma.
Mac Only
The catch here is that -webkit-font-smoothing and -moz-osx-font-smoothing are both vendor-prefixed, which tells you everything about their reach.
On Windows, neither does anything. Windows uses its own renderer called ClearType and it is not overridable through CSS. Windows users will always see subpixel rendering, (Common Windows L).
But this is not a reason to skip the fix. Mac is where the delta between Figma and browser is most visible, and it is where most designers are working and reviewing. But it is worth knowing that you are solving for one side of the equation, not both.
The Catch
Usually you apply * { -webkit-font-smoothing: antialiased } globally and move on in most cases. But if you are using a very thin typeface at small sizes, pay attention to it, because the antialiased removes weight from letterforms, which is usually the point, but on a light font at 14px or lower it can push text into feeling too faint to read comfortably and make the composition look cheap.
A good rule of thumb is to not go below font-weight: 400 at small sizes. And as the font size decreases, push the weight up to compensate. What reads fine at 400 on 16px will need to be slightly bumped at 12px to hold the same presence and legibility on screen.
AA OFF / 300w-13px
AA ON / 300w-13px
After Thoughts
So does “antialiased” mean less antialiasing? Not really. Your text is always antialiased. The property only changes the method behind it. It moves from subpixel, which uses color and renders heavier, to grayscale, which is lighter and cleaner. Nothing is being switched off, you are just choosing how the edges get drawn.
Should I apply it everywhere? In most cases, yes. Set it once on the root and you can forget about it. The only thing to watch is very thin weights at small sizes, where the lighter rendering can leave text feeling faint, so trust your eye on those before shipping.
Does it affect my layout? No. Letter widths, line breaks and spacing stay exactly the same. All that changes is how each glyph meets the pixel grid, so it stays a purely visual shift with nothing moving underneath.
Do font formats matter for this? No. WOFF2, OTF, and TTF are just different ways to package the same glyph outlines, so the format only changes file size and how fast the font loads, not how the text is drawn. The browser decodes any of them down to the same shapes, and then the OS rasterizer is what applies the antialiasing. Use WOFF2 on the web because it is the smallest and best supported, but it renders identically to the rest.
And on dark backgrounds? This is where it shows the most. Subpixel rendering is at its heaviest on dark surfaces, so moving to grayscale is what keeps light text crisp and close to the design. See Example
Thanks to Rauno
I came across this in Rauno's Web Interface Guidelines a while back and have been using it ever since. It made a noticeable difference in how my work looked in production, both for my own projects and for clients.
But as more designers and not only start crossing into engineering territory, I keep noticing the same issue coming up, people have no reference point for what actually happens when a design hits a real browser on real hardware.
So I wanted to elaborate on what is actually going on under the hood.