Wiki · Concept · Last reviewed June 25, 2026

Local Font Access API

The Local Font Access API lets selected web pages enumerate installed fonts and read font data, creating a browser boundary for design tools, agents, and fingerprinting risk.

Category: Concept Updated: June 25, 2026 Tags: browser security, typography, privacy, agents, permissions

Definition

The Local Font Access API is a web-platform capability for applications that need to discover and use fonts installed on a user's device. The WICG draft describes an API for enumerating local fonts, identifying font families and instances, and providing access to the raw bytes of font data. The API is currently specified for Window contexts rather than workers.

MDN marks the API as limited availability and experimental. Its core surface is Window.queryLocalFonts(), which returns a promise for an array of FontData objects. A FontData object represents a single local font face and exposes read-only name fields such as family, full name, PostScript name, and style, plus a blob() method for a Blob containing the raw bytes of the underlying font file.

Mechanism

A page calls queryLocalFonts(). MDN says the method is available only in secure contexts in supporting browsers, requires the user to grant the local-fonts permission, and may be blocked by Permissions Policy. MDN also documents an optional postscriptNames filter so a page can request only matching PostScript names instead of every local face the browser is willing to return.

Chrome's developer documentation frames the use case around professional design and graphics tools. Web fonts can serve many publishing needs, but browser-based editors may need installed fonts for document fidelity, OpenType layout, glyph-level operations, export, or compatibility with legacy font stacks. Chrome describes the API as two parts: font enumeration and byte-oriented SFNT container access through each result.

The same mechanism creates a privacy boundary. A local font list can identify operating system defaults, language packs, creative tools, corporate templates, accessibility packages, client brand systems, games, and niche communities. The WICG draft and MDN both note mitigations such as permission, secure contexts, Permissions Policy, and sorting or limiting returned data. Those controls reduce risk; they do not make installed fonts ordinary public data.

Agent Context

For AI Browsers and Computer Use, local font access is a creative-tool authority surface. An agent in a browser design suite could inspect installed fonts, match a brand system, repair a slide deck, export a PDF, or warn that a document depends on unavailable typefaces. It could also over-collect a complete font inventory, upload font blobs to a remote service, infer workplace identity from proprietary fonts, or silently substitute typefaces in a way that changes meaning, accessibility, or legal compliance.

Fonts are also labor records. A font may represent a purchased license, a client brand package, an internal product family, a union newsletter template, a script for a language community, or a dyslexia-friendly reading setup. Treating fonts as mere styling hides that social layer. Agentic design tools should therefore make font inspection, font byte access, export decisions, and substitutions visible to the user.

Governance Use

A governance review should treat local fonts as device inventory and possibly licensed material. Record the origin, secure-context state, frame context, permission state, prompt text where available, requested PostScript filters, returned metadata fields, whether blob() was called, destination of font data, retention period, and whether a model-generated action requested or copied font files. If a model is involved, record the prompt, selected font, generated substitution, export path, and human approval.

Organizations should separate legitimate document rendering from broad font surveillance. A design editor may need selected fonts for a user-opened file. A helpdesk page, ad script, analytics snippet, or embedded model plugin should not receive a full local font inventory because it happens to run inside the same browser session.

Limits

Permission prompts help, but they do not explain font licensing, client confidentiality, accessibility needs, or cultural context. A user may approve access to make one document render correctly without intending to disclose every installed font or allow font files to be retained for model training, profiling, or asset extraction.

The safer pattern is narrow requests, explicit reason text, local processing where possible, no background inventory, no hidden uploads of font blobs, clear substitution records, and deletion controls. If a web agent suggests installing, removing, or replacing a font, the action should be treated as a document-integrity change, not a cosmetic preference.

Review Record

Source Discipline

Claims about API scope and raw font data access should cite the WICG draft. Claims about secure contexts, queryLocalFonts(), FontData, permissions, and Permissions Policy should cite MDN. Claims about professional design-tool use cases, desktop Chromium availability, and fingerprinting concerns should cite Chrome's developer documentation. A permission grant is evidence of user-mediated access, not evidence that every returned font should be copied, uploaded, retained, or used for profiling.

Spiralist Reading

Spiralism reads local fonts as cultural memory installed at machine scale. A typeface can carry profession, language, client, disability accommodation, institution, taste, and history. The Local Font Access API makes that memory legible to a page. The humane boundary is narrow access, explicit purpose, local-first processing, legible substitution, and a user who can still decide when the machine may read the alphabet behind the document.

Sources

Return to Wiki