> For the complete documentation index, see [llms.txt](https://argos-ci.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://argos-ci.com/docs/learn/reliability-and-flakiness/flaky-tests/stabilize-text-rendering.md).

# Stabilize text rendering

Disable subpixel text and font hinting in headless Chromium to reduce glyph rendering differences between machines.

Reduce glyph rendering differences between machines: disable subpixel (LCD) text and font hinting in headless Chromium. This removes one of the most common sources of screenshot noise. It does not make macOS and Linux render text identically, so capture your screenshots in a single environment, usually CI.

### Why text causes flaky screenshots

By default, Chromium renders text using two techniques that depend on the underlying operating system, GPU, and font stack:

* **Subpixel (LCD) antialiasing** uses the red, green, and blue subpixels of a screen to smooth glyph edges. It leaves faint red/blue color fringing that differs from one machine to another.
* **Font hinting** snaps glyphs to the pixel grid. The result varies between platforms, shifting antialiasing by a pixel here and there.

The consequence: a screenshot captured locally on macOS rarely matches the exact same screenshot captured on a Linux CI runner. Argos sees these sub-pixel differences as real changes and reports false positives, even though no code changed.

### The fix

Launch Chromium with two flags that remove the most variable parts of text rendering:

* `--disable-lcd-text` — forces **grayscale antialiasing** instead of subpixel rendering, removing the red/blue edge fringing.
* `--font-render-hinting=none` — disables font hinting, so glyphs are no longer snapped to each platform's pixel grid. Chromium only reads this flag in headless mode (the headless shell Playwright uses by default); it has no effect on a headed browser.

{% tabs %}
{% tab title="Playwright" %}
Add the launch options to the `use` block of your Playwright configuration:

{% code title="playwright.config.ts" %}

```ts
import { defineConfig } from "@playwright/test";

export default defineConfig({
  use: {
    launchOptions: {
      args: ["--disable-lcd-text", "--font-render-hinting=none"],
    },
  },
});
```

{% endcode %}
{% endtab %}

{% tab title="Storybook (Vitest)" %}
Pass the launch options to the Playwright provider in your Vitest configuration:

{% code title="vitest.config.ts" %}

```ts
import { defineConfig } from "vitest/config";
import { playwright } from "@vitest/browser-playwright";

export default defineConfig({
  test: {
    browser: {
      enabled: true,
      provider: playwright({
        launchOptions: {
          args: ["--disable-lcd-text", "--font-render-hinting=none"],
        },
      }),
      instances: [{ browser: "chromium" }],
    },
  },
});
```

{% endcode %}
{% endtab %}
{% endtabs %}

{% hint style="success" %}
These flags reduce text rendering differences **across** environments. They don't remove them: a system font stack resolves to different fonts on each operating system, and macOS and Linux rasterize glyphs differently. Compare screenshots captured in the same environment; with Argos, baselines come from your CI builds.
{% endhint %}

{% hint style="info" %}
Rendering flakiness is reduced even further when local and CI runs share the **exact same environment** (OS and browser). See [Browser Glitches](/docs/learn/reliability-and-flakiness/flaky-tests/browser-glitches.md) for more on standardizing environments.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://argos-ci.com/docs/learn/reliability-and-flakiness/flaky-tests/stabilize-text-rendering.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.