How Chromium's Local Font Access API Powers Web Design

This article explains how the Local Font Access API in Chromium-based browsers allows web-based graphic design tools to access and utilize a user's locally installed computer fonts. It covers the historical limitations of web typography, the permission-based security model required to trigger the API, the process of enumerating system fonts, and how applications extract raw binary data to render custom typography directly in the browser.

Overcoming Web Font Limitations

Historically, web browsers restricted websites from viewing a user's locally installed fonts to protect privacy and prevent browser fingerprinting. Because of this restriction, web-based graphic design platforms had to rely on users manually uploading font files or installing local desktop helper applications to bridge the gap between the operating system and the browser. The Local Font Access API, implemented in Chromium, solves this by providing a standardized, secure two-step interface for web applications to request direct access to the host computer's font directory.

The Permission Model

Before a graphic design website can view or use any local fonts, it must obtain explicit permission from the user. The API is gated behind a strict security model to prevent unauthorized data harvesting.

The process begins when the user performs a deliberate action on the website, such as clicking a "Load Local Fonts" button. This user gesture allows the website to execute the window.queryLocalFonts() JavaScript method. Chromium intercepts this call and displays a native browser permission prompt. If the user denies the request, the API throws an error and blocks access. If the user grants permission, the browser opens the bridge between the local operating system and the web application.

Enumerating System Fonts

Once permission is granted, the window.queryLocalFonts() method resolves and returns an array of FontData objects. Each object in this array represents a specific font face installed on the host computer. The graphic design website reads this array to populate its own custom font-picker user interface.

Each FontData instance exposes four specific metadata properties that allow the web application to organize and group the fonts correctly:

• family: The general font family name (e.g., "Helvetica").
• fullName: The complete, human-readable name of the specific font (e.g., "Helvetica Bold Oblique").
• postscriptName: A unique, standardized identifier used by operating systems and rendering engines (e.g., "Helvetica-BoldOblique").
• style: The specific style classification (e.g., "Bold Oblique").

If a design tool only needs to check for the existence of a few specific fonts used in an existing document, it can pass an array of postscriptNames into the queryLocalFonts() method to filter the results rather than enumerating the entire system library.

Accessing Raw Font Data for Rendering

Simply knowing the name of a local font is enough for basic CSS styling, but professional graphic design tools rarely use standard browser text rendering. Instead, they use custom rendering engines built on HTML5 Canvas and WebGL to ensure pixel-perfect accuracy across different computers. These engines require access to the actual font files to calculate vector paths and glyph outlines.

To enable this, the Local Font Access API provides a .blob() method on every FontData object. When a user selects a specific font from the website's dropdown menu, the application calls the .blob() method on that font's data object.

This method asynchronously fetches the raw binary data—the underlying SFNT wrapper containing TrueType (.ttf) or OpenType (.otf) tables—directly from the host computer's hard drive. Once the website possesses this Blob of raw bytes, it can feed the data into WebAssembly-based text shaping libraries (like HarfBuzz) or custom vector renderers. This allows the web application to manipulate kerning, convert text to vector outlines, and render the local font onto a design canvas just like a native desktop application.