The Local Font Access API opens a protected library
Professional design tools need to know which fonts are available on a computer. A browser-based layout app, illustration editor, or publishing system may need exact family names, styles, and font data to render a project faithfully. The Local Font Access API gives web applications a direct route to that information—but only after the user grants permission.
That gate matters because a font collection can be surprisingly personal. Operating systems ship different defaults. Creative applications install additional families. Users add fonts for work, language support, hobbies, or client projects. A detailed list can reveal both software choices and a distinctive device profile.
What the API lets a website request
A supporting site calls window.queryLocalFonts(). After permission is granted, the result contains FontData objects describing locally installed faces. According to the MDN Local Font Access API guide, those objects can expose a PostScript name, full name, family, style, and even a blob containing the underlying font data.
That level of access solves real problems. A desktop publishing app can populate an accurate font picker. A design tool can preserve typography when opening a local document. A specialist editor can inspect a font format or render text with the same resources used by native software.
MDN marks the API experimental and not Baseline because it is unavailable in some widely used browsers. Chrome documents desktop support beginning with version 103, but developers still need feature detection and a fallback such as uploaded font files or web fonts.
Why a font list can identify a device
Common operating-system fonts do not say much by themselves. Rare combinations do. A machine with a particular language pack, office suite, type foundry collection, and several niche fonts may stand out from most visitors. Font versions can add still more detail.
The Local Font Access specification describes these sources of fingerprinting entropy directly: fonts bundled with the operating system, fonts installed by applications, fonts installed by an administrator or user, and version information within font data.
This is an example of the broader technique in our article on how websites fingerprint browsers without cookies. Trackers do not need one perfect identifier if they can combine enough moderately distinctive signals. Fonts, screen dimensions, language, time zone, graphics behavior, and hardware hints can reinforce one another.
Permission changes the privacy model
The modern API does not silently hand every page a full inventory. Calling queryLocalFonts() triggers a permission request. In Chrome, the local-fonts permission is visible in site information, persists across reloads, and can be revoked later. This makes the access legible and connected to a specific origin.
Users should judge the request by the task. Granting access to a trusted design application while choosing fonts is easy to justify. The same request from a news article, coupon page, or unrelated embedded widget deserves refusal. A clear explanation should arrive before the browser prompt, not after it.
Permission does not make data harmless. It creates accountability and gives the user a decision point. Developers still need to minimize collection, avoid transmitting font inventories unnecessarily, and discard information when the task ends.
How Permissions Policy limits embedded content
Local font access is also controlled by Permissions Policy. The MDN local-fonts directive reference says the default allowlist is self. A third-party iframe therefore cannot simply inherit access without the top-level site allowing it.
This second boundary is important. A person may trust the application visible in the address bar without knowing every analytics, support, or advertising frame it embeds. Site owners can use the header to keep the capability within the origin that actually provides the editing feature.
Our guide to Permissions Policy and browser privacy explains how this mechanism delegates powerful features. It does not replace the user's permission decision; it narrows which documents are eligible to ask.
Local fonts are different from ordinary web fonts
A web font is normally downloaded from a URL chosen by the page. It gives the site consistent typography without revealing the rest of the computer's collection. A local font reference can avoid a download when a named face exists, but older techniques for testing many names became notorious as a fingerprinting surface.
The Local Font Access API addresses a narrower professional need with an explicit permission model. It should not become a convenience shortcut for ordinary page styling. Most websites can use self-hosted web fonts, system-font stacks, or a small set of downloaded assets without enumerating the device.
Raw font access also carries licensing and confidentiality considerations. A font installed for a private project may not be licensed for upload or redistribution. Applications should process font data locally when possible and avoid sending complete files to a server unless the user knowingly requests that workflow.
A practical checklist for users
- Grant local-font access only when the site's core editing task clearly needs it.
- Check the domain in the address bar before approving the request.
- Deny the permission on ordinary content, shopping, or advertising pages.
- Review saved site permissions and remove access you no longer use.
- Remember that private browsing may behave differently across browsers.
A practical checklist for developers
- Explain the feature before invoking the permission prompt.
- Request access after a user action, such as opening a font picker.
- Query only the font names needed when the API allows filtering.
- Keep enumeration and rendering on the device whenever possible.
- Do not repurpose font data for analytics, advertising, or fraud scoring.
- Provide a functional fallback for unsupported or denied access.
Developers should treat denial as a normal outcome, not an error to pressure the user into reversing. The same principle appears throughout our browser permissions guide: ask in context, state the benefit, and preserve useful functionality when the answer is no.
The Local Font Access API shows how the web can approach desktop-class capability responsibly. Advanced creative tools gain a path to precise typography, while the browser adds a permission prompt, origin scoping, and policy controls. That balance works only when sites use the access for the task the user intended—and nothing more.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.