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 Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: 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.

The API should be understood as a narrow professional-design capability, not a general right for websites to inventory a device. The privacy-sensitive object is both the list of installed fonts and the font bytes themselves. Either can reveal language, occupation, organization, client work, accessibility tools, software history, or licensed creative assets.

Current Context

As of this June 25, 2026 review, the Local Font Access API remains a WICG Community Group draft rather than a W3C Standard or standards-track recommendation. The draft date shown on the specification is June 7, 2024, and the document states that it is published by the Web Platform Incubator Community Group.

Chrome's developer documentation says the API is available from Chrome 103 on desktop. MDN, however, labels queryLocalFonts() as limited availability and experimental because it does not work in some widely used browsers. Production and procurement claims should therefore name the browser, platform, version, permission behavior, and fallback path rather than saying simply that "the web supports local font access."

The API's current governance importance comes from the browser capability pattern it represents: a web app asks to cross a local-device boundary for a creative purpose, but the returned data can be reused for tracking, asset extraction, licensing disputes, model input, or workplace inference if the surrounding system is not constrained.

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.

The WICG draft defines local-fonts as a powerful feature and a policy-controlled feature with a default allowlist of 'self'. Same-origin nested frames may use the feature by default, while third-party frames require explicit delegation such as allow="local-fonts". The feature can also be disabled with a Permissions-Policy header such as Permissions-Policy: local-fonts 'none'.

The draft also requires transient user activation for queryLocalFonts(). That means a well-designed app should tie the request to a visible user action, such as opening a document-font repair flow or selecting fonts for export. A background analytics script, ad frame, or agent helper should not call the API just because it can.

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.

Boundary Tests

Not ordinary CSS fallback. CSS can request local fonts by name through normal font matching, but this API exposes an enumerable inventory and can expose font bytes. That is a different privacy and licensing boundary.

Not File System Access. File System Access API grants access to user-selected files or directories. Local Font Access is scoped to system font representations returned by the browser and should not be treated as permission to browse the user's font folders or other design assets.

Not a license grant. Reading font bytes through the browser does not prove the web app may upload, store, embed, redistribute, train on, or transform the font. License and client-confidentiality checks remain separate governance work.

Not consent for profiling. A user may allow a design tool to check whether a document can render correctly. That does not authorize font-based fingerprinting, workplace inference, targeted advertising, or model-improvement reuse.

Not a general agent permission. An AI agent repairing a design file still needs task scope, user approval, audit trails, and upload controls before reading font bytes or changing document typography.

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.

The API also belongs in vendor and platform governance. Enterprise design suites, browser-based PDF tools, AI slide generators, brand-management systems, and low-code document tools should declare whether they enumerate all fonts or filter by PostScript name, whether they ever call blob(), whether font bytes leave the device, whether they use font data for model training or analytics, and whether users can delete stored font artifacts.

For high-risk settings, such as legal documents, medical forms, identity documents, government notices, ballots, contracts, accessibility templates, or client brand systems, font substitution can be a document-integrity event. The review should preserve before/after fonts, layout changes, accessibility impact, export settings, and the person or agent that approved the change.

Failure Modes

Inventory laundering. A creative feature quietly becomes a device fingerprint or workplace-profile signal.

Font-byte exfiltration. A page or model plugin calls blob() and uploads licensed fonts to a remote service without a clear need, retention rule, or license review.

Frame delegation drift. A first-party design app delegates local-fonts to an embedded third party whose business purpose is analytics, ads, support, or model evaluation rather than document rendering.

Agent substitution. An AI tool replaces fonts to make an export succeed, but the substitution changes pagination, branding, accessibility, evidence fidelity, or legal meaning.

Permission overread. A user grants access for one document, while the application treats the grant as consent to keep a complete font profile for future personalization or training.

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.

Browser support is also a limit. MDN's limited-availability warning means applications should not make local-font access the only path for core functionality. Good fallbacks include user-selected font files, embedded licensed web fonts, document-package inspection, server-side rendering with declared fonts, or a clear degraded mode.

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.

Implementation claims should be dated. The WICG draft is not a W3C Standard, MDN marks the feature experimental and not Baseline, and Chrome's documentation is Chrome-specific. Security reviews should treat browser compatibility tables, enterprise browser policy, installed web app mode, iframe delegation, and extension context as evidence inputs rather than assuming one uniform browser behavior.

Claims about AI or agent use should cite the actual product behavior, not the API alone: whether the product queried all fonts, filtered by PostScript names, called blob(), uploaded bytes, retained metadata, trained a model, or changed an exported document. The API creates the capability; the product creates the governance risk.

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.

Open Questions

Sources

Return to Wiki