How to test typography across devices and browsers?

To test typography across devices and browsers, start with a short matrix of the browser engines and operating systems your visitors use, then check each one against a fixed list: which font actually rendered, how it looks at small and large sizes, line length and wrapping at each breakpoint, behaviour while fonts load, and how text holds up under user settings such as zoom, larger default font sizes, dark mode and forced colours. Use browser DevTools to confirm the rendered font, real phones and laptops to judge how text actually looks, and automated screenshot tests to catch regressions. Text renders differently on Windows, macOS, Android and iOS because each platform rasterises fonts in its own way, so no single machine can tell you how your type looks to everyone.

Typography bugs are easy to miss because they rarely break anything outright. A fallback font that silently replaces your web font, a heading that wraps to leave one word on a line on a mid-sized phone, or body text that looks thin and spidery on Windows will still pass most functional tests. In this article you'll learn why text renders differently across platforms, how to build a sensible test matrix, what to check on each device, how to use DevTools to inspect fonts, how to test accessibility settings, and how to automate visual checks.

Why Text Looks Different Across Platforms

The same font file at the same size can look noticeably different depending on where it's displayed.

• Rasterisation and hinting: Windows uses DirectWrite, with ClearType-style subpixel rendering on many setups, and tends to snap glyphs closer to the pixel grid. macOS doesn't apply font hinting and preserves the outline's shape, which can make text look softer and slightly heavier. Android and iOS have their own approaches.
• Pixel density: On high-density screens, most rendering differences shrink. On standard-density monitors, which are still common on Windows desktops and office machines, thin weights and fine serifs can break up.
• Font availability: System font stacks resolve to different fonts on each platform. system-ui is San Francisco on Apple devices, Segoe UI on Windows and usually Roboto on Android.
• Engine differences: Chromium, WebKit and Gecko differ in support for newer CSS features such as text-wrap: pretty, text-box and some font-related properties, and in how they synthesise missing bold or italic styles.
• Default settings: Users can change the default font size, minimum font size and, in some browsers, the default fonts themselves.

That's why testing on one MacBook isn't enough. Windows on a standard-density screen is often where thin fonts and low-contrast greys fail first.

Build a Test Matrix

You can't test every combination, so pick a representative set. Start with your analytics to see which browsers, operating systems and screen sizes your visitors actually use, then cover each major engine on each major platform.

Engine	Platform	Why it matters
Chromium (Chrome, Edge)	Windows, standard-density display	Different rasterisation, often the harshest test for thin weights
Chromium (Chrome)	Android phone	Small screens, Roboto as the system font
WebKit (Safari)	iPhone	All iOS browsers use WebKit, so this covers Chrome on iOS too
WebKit (Safari)	macOS	Unhinted rendering on high-density screens
Gecko (Firefox)	Windows or macOS	Different line breaking and font fallback details

Add specific devices if your audience demands it, such as older Android phones with lower-resolution screens or large desktop monitors.

What to Check on Every Device

Work through the same checklist each time, so results are comparable.

1. The right font rendered: Every weight and style you use actually loaded, with no fallback font in its place.
2. Weights look correct: Bold is real bold, not a synthesised version, and light weights remain legible.
3. Size and line height: Body text is comfortable to read at arm's length on a phone and at normal distance on a desktop.
4. Line length: Body text stays roughly within 45 to 75 characters per line at each breakpoint.
5. Wrapping: Headings don't leave a single word on the last line, long words and URLs don't overflow, and buttons don't wrap awkwardly.
6. Loading behaviour: Text is visible quickly, and the swap from fallback to web font doesn't cause a large layout shift.
7. Special characters: Accented letters, curly quotes, dashes, currency symbols and any non-Latin scripts you support all render in the intended font.
8. Numbers: Tables and prices align properly if you use tabular figures.

Use a page that contains realistic content: a long article, a form, a table, a navigation menu and a product card. Short placeholder text hides wrapping problems.

A Typography Test Page

A dedicated test page that gathers your tricky cases in one place speeds up every round of testing:

<main class="type-test">
  <h1>
    A deliberately long page heading that has to wrap across several lines
  </h1>
  <p>
    Regular, <em>italic</em>, <strong>bold</strong> and
    <strong><em>bold italic</em></strong
    >.
  </p>
  <p>Accents: café, naïve, Zürich, São Paulo, Kraków, Dvořák.</p>
  <p>
    Punctuation: “quotes”, ‘single’, en dash 2024–2026, em dash — and ellipsis…
  </p>
  <p>Currency and numbers: £1,299.00 · €49 · $0.99 · 1234567890</p>
  <p>
    A long URL:
    https://example.com/a/very/long/path/that/might/overflow/its/container
  </p>
  <table>
    <tr>
      <td>Widgets</td>
      <td class="num">1,204.50</td>
    </tr>
    <tr>
      <td>Gadgets</td>
      <td class="num">98.10</td>
    </tr>
  </table>
</main>

Inspect Fonts With DevTools

The CSS font-family value tells you what you asked for. DevTools tells you what the browser actually used.

Chrome and Edge

Select a text element, open the Computed tab in the Elements panel, and scroll to the bottom. The Rendered Fonts section lists the font family that drew the text and how many glyphs came from each font. If it says "Arial" or "Times New Roman" where you expected your web font, the font didn't load or doesn't cover those characters.

The Network panel, filtered by Font, shows which font files downloaded, how large they were and how long they took. The Rendering drawer can emulate prefers-color-scheme, prefers-reduced-motion, forced colours and vision deficiencies.

Firefox

Firefox's Inspector has a dedicated Fonts panel. It lists the fonts used on the selected element, shows whether each is a system or web font, and for variable fonts provides sliders for every axis, which is handy for testing weight and optical size settings.

Safari

In Safari's Web Inspector, select an element and open the Font section of the details sidebar, which shows the font used along with its supported features and variation axes.

Check Fonts From the Console

The CSS Font Loading API lets you check what has loaded from any browser's console:

await document.fonts.ready;

for (const face of document.fonts) {
  console.log(face.family, face.weight, face.style, face.status);
}

console.log(document.fonts.check('700 1rem "Inter"'));

Inter 400 normal loaded
Inter 700 normal loaded
Inter 400 italic unloaded
true

A face with the status unloaded hasn't been requested yet, often because nothing on the page uses that style. A status of error means the file failed to load. Be aware that document.fonts.check() also returns true when no matching face is declared at all, so the status list is the more reliable signal.

Test Real Devices, Not Just Emulators

Device emulation in DevTools is excellent for checking layout at different widths, but it doesn't change how fonts are rasterised. A Windows laptop emulating an iPhone still renders text like Windows.

• Use real phones: Look at body text on an actual phone held at a normal reading distance. Size and weight decisions that look fine on a big monitor can feel tiny or heavy on a phone.
• Use a standard-density screen: If your team uses high-density laptops, borrow or buy an inexpensive standard-density monitor to check thin weights and fine details.
• Use cloud device services: Services such as BrowserStack, LambdaTest and Sauce Labs give you remote access to real devices and browsers, which fills gaps in your own collection.
• Test in daylight and at night: Contrast problems and heavy dark-mode text become obvious in different lighting.

For quick checks of a local site on your own phone, expose your development server on your network:

npx vite --host

  VITE v6.0.0  ready in 310 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: http://192.168.1.24:5173/

Open the Network address on a phone connected to the same Wi-Fi network. For Safari on iOS and Chrome on Android, you can also connect the phone to your computer and use remote debugging, so you can inspect fonts on the real device.

Test Accessibility and User Settings

Many readers change how text is displayed. Your typography must survive those changes.

Zoom and Default Font Size

WCAG 2.2 success criterion 1.4.4 requires text to be resizable up to 200 per cent without loss of content or functionality. Test both browser zoom and a larger default font size in browser settings. The second catches font sizes set in px, which ignore the user's default size.

Reflow

Success criterion 1.4.10 requires content to reflow at a width equivalent to 320 CSS pixels without horizontal scrolling for normal text. Set the viewport to 320px wide, or zoom a 1280px window to 400 per cent, and check that text wraps rather than overflowing.

Text Spacing

Success criterion 1.4.12 requires that no content is lost when users set line height to at least 1.5 times the font size, paragraph spacing to at least 2 times, letter spacing to at least 0.12 times and word spacing to at least 0.16 times. Inject this CSS through DevTools or a bookmarklet to test it:

* {
  line-height: 1.5 !important;
  letter-spacing: 0.12em !important;
  word-spacing: 0.16em !important;
}

p {
  margin-block-end: 2em !important;
}

Look for text that's cut off, overlapping or hidden inside fixed-height containers such as buttons, cards and badges.

Dark Mode and Forced Colours

Emulate prefers-color-scheme: dark and check that text contrast is still adequate and that light-on-dark text doesn't look too heavy. Then turn on Windows contrast themes, or emulate forced-colors: active in DevTools, and make sure text, links and focus outlines are still visible.

Automate Visual Regression Tests

Manual testing catches most issues, but automated screenshots catch the ones that sneak in later, such as a font file that stops loading after a build change. Playwright can run the same test in Chromium, Firefox and WebKit.

// playwright.config.ts
import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  testDir: "./tests",
  use: { baseURL: "http://localhost:3000" },
  projects: [
    { name: "chromium", use: { ...devices["Desktop Chrome"] } },
    { name: "firefox", use: { ...devices["Desktop Firefox"] } },
    { name: "webkit", use: { ...devices["Desktop Safari"] } },
    { name: "mobile-chrome", use: { ...devices["Pixel 7"] } },
    { name: "mobile-safari", use: { ...devices["iPhone 15"] } },
  ],
});

// tests/typography.spec.ts
import { test, expect } from "@playwright/test";

test("type test page renders with web fonts", async ({ page }) => {
  await page.goto("/type-test");
  await page.evaluate(() => document.fonts.ready);

  const loadedWeights = await page.evaluate(() =>
    [...document.fonts]
      .filter(
        (f) => f.family.replace(/"/g, "") === "Inter" && f.status === "loaded",
      )
      .map((f) => f.weight),
  );
  expect(loadedWeights).toEqual(expect.arrayContaining(["400", "700"]));

  await expect(page).toHaveScreenshot("type-test.png", { fullPage: true });
});

npx playwright test tests/typography.spec.ts

Running 5 tests using 5 workers
  5 passed (14.2s)

The first run creates baseline screenshots, and later runs compare against them. Waiting for document.fonts.ready before taking the screenshot prevents false failures caused by fallback fonts. Screenshots differ slightly between operating systems because of font rendering, so generate and compare baselines on the same platform, typically in a Docker image in CI.

---

FAQ: Testing Typography

---

Conclusion

Testing typography across devices and browsers means accepting that text never looks exactly the same everywhere. Each platform rasterises fonts differently, system font stacks resolve to different typefaces, and browser engines differ in which typographic CSS they support. Build a small matrix that covers each major engine on each major platform, use a test page with realistic content, and confirm with DevTools which fonts actually rendered.

Then go beyond the defaults. Look at real phones and a standard-density screen, test zoom, reflow, text spacing, dark mode and forced colours, and add automated screenshot tests that wait for fonts before capturing. Together, those checks catch the quiet typography failures that functional tests miss and make sure every reader gets text that's comfortable to read.