Choosing a Primary Font for Your Design System

The primary font in a design system is the most consequential single design decision you will make. It appears in every product that consumes the system, at every font size, on every surface, across every platform. A poor choice creates friction for every designer and developer who follows — a face that renders poorly at small sizes, one that lacks the weights needed for a legible hierarchy, or one whose licensing restricts how it can be used in the products you build.

This guide works through the criteria that matter most for system-level font selection and evaluates the leading candidates against those criteria.

Requirements for a System-Level Font

A font chosen for personal use or a one-page marketing site faces lighter requirements than a font chosen for a design system. At the system level, the font must perform well across a much wider range of contexts simultaneously.

Legibility at small sizes. Enterprise UIs, dashboards, and dense data tables all require text at 11–14px. A font that looks elegant at 24px but deteriorates at 12px is unsuitable. Look for a typeface with a generous x-height and open apertures — features that keep letters distinguishable when rendered at small sizes.

Sufficient weight range. A practical system font needs at minimum: Light or Regular (300–400) for body text and secondary content, Medium or Semibold (500–600) for labels, navigation, and subheadings, and Bold or Black (700–800) for headings and emphasis. If the typeface supports fewer than four or five distinct weights, you will find yourself working around its limitations.

Variable font support. Variable fonts consolidate multiple weights into a single file and allow intermediate weights that don't exist in static font families. For a design system serving products with diverse density requirements, variable font support reduces HTTP requests and provides precise control over weight. A static four-weight family served as four separate files is technically inferior to a single variable font file covering the same range.

Extensive language and character support. Products scale across markets. A design system that commits to a font supporting only Latin characters will face a painful migration when the product expands to Turkish, Vietnamese, or Arabic-script languages. Evaluate Unicode coverage before committing.

Clear licensing for design systems. Licensing at the system level is more complex than for a single product. If your design system is used by external customers — an embedded white-label product, a developer platform, or a component library distributed as open source — the font's license must permit those use cases. Read the license carefully.

Character Set and Language Coverage

Most modern system fonts claim "extended Latin" support, but the specifics vary significantly. Here is what to check:

Basic Latin + Western European: The minimum. Covers English and major Western European languages (French, German, Spanish, Italian, Portuguese, Dutch).

Extended Latin: Covers Central and Eastern European languages (Czech, Polish, Hungarian, Romanian). Includes characters like ě, ą, ő, ș.

Vietnamese: Vietnamese orthography uses extensive diacritics (tonal marks stacked on vowels) that many fonts handle poorly or not at all. Vietnamese is used by nearly 100 million people, and if your product targets Southeast Asia, this coverage is not optional.

Greek and Cyrillic: Greek covers 11 million users in Greece and Cyprus plus Greek used in scientific notation. Cyrillic covers Russian, Bulgarian, Ukrainian, Serbian, and others — a combined user base of several hundred million.

Arabic, Hebrew, Thai, Devanagari, CJK: These script families require specialized design work. If your products will localize into these scripts, you have two options: choose a super-family that covers them (very few do well), or plan for a script-specific fallback font that harmonizes reasonably with your primary font.

Practical approach: Check your product roadmap for the next three years. What languages will you support? Verify coverage in the font's character map before committing. A font that works for today's English-only product but lacks Vietnamese support will force a system-level font migration if you expand to Vietnam.

Weight Range and Variable Font Support

Evaluating weight range:

For a rich typographic hierarchy, you want at least five distinct weights. The named weights in CSS correspond to numeric values:

A font with weights 300, 400, 500, 600, 700 provides enough differentiation for most design systems. A font with only 400 and 700 makes it difficult to create subtle hierarchy in dense interfaces.

Variable font considerations:

Variable fonts use the font-weight CSS property as a continuous range rather than discrete values. With a variable font that covers 100–900, you can set font-weight: 450 — a weight that does not exist in any static font file.

@font-face {
  font-family: 'Inter Variable';
  src: url('/fonts/InterVariable.woff2') format('woff2');
  font-weight: 100 900;  /* weight range the variable font covers */
  font-style: normal;
  font-display: swap;
}

/* Using a specific non-standard weight */
.label {
  font-family: 'Inter Variable', sans-serif;
  font-weight: 450; /* valid for variable fonts */
}

Variable fonts also support the font-variation-settings property for direct axis control, useful when a font has axes beyond weight (such as optical size opsz or width wdth).

.small-label {
  font-variation-settings: 'wght' 500, 'opsz' 12;
}

Browser support for variable fonts is now effectively universal (all modern browsers, including mobile). The practical benefit is significant: a single variable font file replaces five or six static files, reducing the number of HTTP requests and often reducing total bytes transferred when multiple weights are used.

Licensing for Design Systems

Font licensing is frequently misunderstood. "Free for commercial use" does not automatically mean licensed for all design system use cases. The specific scenarios to clarify:

Web use: Does the license permit embedding in web pages via @font-face? Most modern licenses (including SIL OFL) do. Some commercial licenses restrict to desktop use only, or charge per-page-view.

Desktop embedding in apps: Native iOS and Android apps embed font files directly in the app binary. Some font licenses require a separate "embedding" license for this use case.

Redistribution: If your design system is distributed as an open-source component library that includes the font files, the font license must permit redistribution. The SIL Open Font License explicitly permits redistribution as long as the font is not sold on its own.

White-label or embedded products: If your company builds software that other companies embed in their products, and those products use your design system's fonts, the downstream use needs to be covered by the license.

The safest choice: Fonts released under the SIL Open Font License (OFL) are the most permissive for design system use. OFL fonts can be freely used, studied, modified, and redistributed. Almost every Google Font is released under OFL. This is why Google Fonts has become the default choice for many design systems — zero licensing complexity.

Google Fonts-specific consideration: Serving fonts directly from fonts.googleapis.com sends your users' IP addresses to Google's servers with each request. For GDPR-compliant products serving EU users, self-hosting the fonts (downloading from Google Fonts and serving from your own domain) is both legally cleaner and faster (avoids a cross-origin DNS lookup).

Rendering Across Platforms

A font that renders beautifully on macOS at 2x Retina may look noticeably different on Windows at 1x or 1.5x display density. Cross-platform rendering differences are a real concern for design systems serving products across operating systems.

Key factors affecting rendering:

Hinting quality. TrueType hinting is a set of instructions embedded in the font that tells the rasterizer how to align outlines to pixel boundaries at small sizes. Good hinting makes a font legible at 12–14px on 1x displays. Poor hinting results in blurry or uneven strokes. On macOS and iOS, Apple's rendering engine largely ignores hints (sub-pixel rendering handles the work). On Windows with GDI rendering, hinting quality matters significantly.

Sub-pixel rendering. macOS uses greyscale anti-aliasing. Windows uses ClearType (RGB sub-pixel) rendering. The same font looks measurably different between these systems. Test your primary font choice on a Windows machine at 1x DPI before committing.

Font smoothing on macOS. The font-smooth CSS property is non-standard but affects macOS rendering. The -webkit-font-smoothing: antialiased declaration switches from sub-pixel to greyscale anti-aliasing, which many designers prefer for UI text at medium and large sizes.

body {
  -webkit-font-smoothing: antialiased;  /* macOS Chrome/Safari */
  -moz-osx-font-smoothing: grayscale;   /* macOS Firefox */
}

The Top Candidates Compared

Inter (designed by Rasmus Andersson) is the most widely recommended system font for web applications in 2024–2025. It was designed specifically for computer screens and optimized at every size. Available as a variable font, covers extensive Latin including Vietnamese, and is released under SIL OFL. Used by Shopify Polaris, Linear, Vercel, Notion, and hundreds of other products. The main criticism: its ubiquity means products using Inter can feel generic. See the Inter specimen for a detailed look at its features.

IBM Plex Sans (designed by Bold Monday for IBM) is an excellent choice for products that need a more distinctive character without sacrificing functionality. It has a slightly more engineered, structured quality that suits developer tools and data products. Available on Google Fonts, SIL OFL, variable font available, good Latin coverage. Used by IBM Carbon and any products that consume Carbon.

Roboto (designed by Christian Robertson for Google) was the default system font for Android and Google's Material Design. It is a geometric grotesque with humanist influences and covers an extensive character set including Cyrillic, Greek, and many extended Latin scripts. Available on Google Fonts, SIL OFL. The variable font (Roboto Flex) is particularly full-featured with nine axes. Used in Material Design 3 and Android apps.

Source Sans (designed by Paul D. Hunt for Adobe) is one of the most mature and technically complete open-source sans-serifs. Source Sans 3 (the current version) is a variable font with weight and italic axes, covers an extensive character set, and has excellent hinting quality for small-size rendering. Available on Google Fonts, SIL OFL. Used in document-heavy products and reading-focused interfaces.

Nunito Sans is a rounded geometric sans with a friendly character suitable for consumer-facing products. Available on Google Fonts, SIL OFL. Less neutral than Inter or Roboto — better for products with a warmer, more approachable brand character.

DM Sans (designed by Colophon Foundry) is gaining adoption for its clean, modern geometry and excellent readability at UI sizes. Available on Google Fonts as a variable font with a wide weight range.

For products requiring CJK language support alongside Latin, the most practical strategy is to use a Latin-optimized primary font (Inter, Source Sans) and specify a system or CJK font as a fallback. Noto Sans (designed for universal language coverage) and Google's Noto CJK families are the standard choices for comprehensive script coverage.

The decision rarely comes down to a single winner — it is a weighted judgment across all these criteria against your specific product's user base, platform requirements, and brand character. But if you need a safe default, Inter's combination of screen optimization, variable font support, extensive weights, SIL OFL licensing, and Google Fonts availability makes it the lowest-risk starting point for most web design systems.