How Websites Actually Deliver Their Fonts

Snapshot of 21 September 2026. The sites in our database are not a random sample of the web - see how we measured.

What we measured, and what we did not

Every time someone runs a URL through the font checker, our scanner fetches the page's HTML, its inline <style> blocks and up to ten linked stylesheets, and parses the @font-face rules and font-provider links it finds. It records, for every font, the src of the rule - and that src names the host that actually delivers the font file. The scanner does not execute JavaScript, so a font that is injected only by a script (a consent-management tool that swaps in Google Fonts after a click, for instance) can be missed. Fonts declared as mere fallbacks in a font-family stack, and system fonts, are not counted as web fonts.

For this study we took every site in our database with at least one real web font: 1,957 sites, as of 21 September 2026. For 1,836 of them the stored rule carried a usable source URL; every percentage in this article refers to those 1,836 sites unless stated otherwise. We then compared the host of each font's source URL with the site's own domain. A font whose file comes from the site's domain or one of its subdomains counts as self-hosted; everything else counts as a third-party host. Google, Adobe and Bunny are recognised by their well-known hostnames.

One more thing became clear while classifying: "self-hosted or CDN" is a false dichotomy. 397 of the 1,836 sites serve fonts from their own domain and from a third-party host at the same time - a self-hosted body face next to a display face from Google, for example. That is itself a finding, and it is why the categories below overlap.

The delivery routes, technically

A web font reaches the visitor in two steps: the browser first needs a stylesheet with an @font-face rule, then it fetches the font file that rule points to. The delivery route determines how many different hosts are involved in those two steps, who controls the caching, and which servers receive requests - and therefore the visitor's IP address - as a side effect.

Self-hosted

The site ships its own @font-face rules and the font files sit on the site's origin, often next to the other static assets: github.com serves Mona Sans from /assets/, nytimes.com serves its Cheltenham and Franklin families from /fonts/family/, heise.de its Source Sans variable font from /assets/fonts/. The browser is already connected to that origin for the HTML, so the font files travel over the same connection; no extra DNS lookup, TCP handshake or TLS negotiation is needed. The site controls every detail: the cache lifetime of the files, the font-display strategy, subsetting via unicode-range, and whether a file is preloaded. No party other than the site itself sees the request. The price is that the site has to do all of that work itself: convert and subset the files, set the cache headers, and keep the licence terms of commercial faces in mind.

web.dev's font guidance states the performance case plainly: "On paper, using a self-hosted font should deliver better performance as it eliminates a third-party connection setup" - and immediately adds the condition that the site should serve them over a CDN and HTTP/2, and that the only way to know for sure is to measure both variants (Best practices for fonts).

Google Fonts

The standard embed is a <link rel="stylesheet"> pointing at fonts.googleapis.com/css2?family=… (CSS API documentation). That host returns a stylesheet, not a font. Google generates this stylesheet for the requesting browser: as the technical considerations page puts it, "the Fonts API serves a stylesheet generated for the specific user agent making the request". We confirmed this on 21 September 2026: the same URL returned woff2 files split into per-script unicode-range subsets to a Chrome user agent, and a single TrueType file to a client without a browser user agent. The font files themselves are then loaded from a second host, fonts.gstatic.com. A page that uses Google Fonts this way therefore talks to three origins before its text can render in the intended face - which is why web.dev recommends a preconnect hint for third-party font hosts, and two of them in this case, because "font files must be sent over a CORS connection" (web.dev).

The CORS requirement is not a Google particularity. The CSS Fonts specification requires font files to be fetched in CORS mode and notes that "fonts will typically not be loaded cross-origin unless authors specifically take steps to permit cross-origin loads" (CSS Fonts Level 4, font fetching requirements; MDN on CORS). Every hosted font service answers with Access-Control-Allow-Origin: * for that reason - Google's hosts did so in our checks.

Caching is split across the two hosts. On 21 September 2026 the stylesheet from fonts.googleapis.com came with Cache-Control: private, max-age=86400, stale-while-revalidate=604800 - cacheable for a day - while a font file from fonts.gstatic.com came with Cache-Control: public, max-age=31536000, a year. In practice the browser revisits the stylesheet host regularly and keeps the files for a long time.

The data flow is the flip side of the request path. Every visitor's browser contacts Google's servers twice, and a server necessarily learns the IP address of the client it answers - that is how HTTP works, not a design decision by Google. What Google does with those requests is described in the privacy section of the Google Fonts FAQ; we refer to it rather than paraphrase it, because it is Google's statement to make. In our data, youtube.com is the textbook example of this route: Roboto and YouTube Sans arrive via fonts.googleapis.com and fonts.gstatic.com.

Adobe Fonts (Typekit)

Adobe Fonts works with a "kit" or web project: the page links a stylesheet on use.typekit.net, and in the sites we scanned the font files referenced by that stylesheet are served from the same host, under use.typekit.net/af/…. That makes it two origins instead of three. The fonts stay on Adobe's servers; that is part of the licensing model, and it is why Adobe collects usage data. Adobe's privacy notice for the service lists what the website font service records - among other things the fonts served, the web project ID, the account ID, the hostname of the page loading the fonts, and the IP address, of which it says: "while the Fonts service receives IP address so that it knows where to deliver the font, it does not store it". The same notice states that "we do not set or use cookies in order to serve our fonts" and names billing and compliance as the purpose (Adobe Fonts privacy notice). Examples in our database include jamesclear.com and princeton.edu.

Monotype and other hosted services

Monotype's hosted web-font service follows the same pattern of a vendor host plus usage reporting: the embed comes with a tracking stylesheet that, in Monotype's words, "tracks web font usage and pushes that usage data back to Monotype Fonts for reporting and licensing purposes", counted as page views per web project (Monotype: Hosting web fonts and reporting). In our data the host static.monotype.com appears with 120 font references - but those come from only two sites, both foundry sites in the Monotype group, each declaring many faces. Keep that in mind when reading the host ranking below.

EU-based alternatives: Bunny Fonts

Bunny Fonts is the best-known of the services positioned as a privacy-friendly replacement for Google's CDN. Its API is designed, in its own words, to be "fully compatible with the Google Fonts CSS v1 API", so that switching is "as easy as changing the hostname"; the service states a "zero-tracking and no-logging policy" and is operated by BunnyWay d.o.o., an EU-based company (About Bunny Fonts). Technically it is the Google route with one host fewer: on 21 September 2026 the stylesheet at fonts.bunny.net/css?family=… pointed at font files on the same host and was served with Cache-Control: public, max-age=2592000. Whether the no-logging statement holds is something we cannot measure from the outside; we report the provider's claim as a claim.

A fourth route nobody chooses: the site builder's CDN

Three of the seven most frequent third-party hosts in our data are not font services at all. Webflow documents that uploaded assets are "delivered via our content delivery network" (Webflow: Asset privacy); in our scans that CDN answers to cdn.prod.website-files.com, and Webflow's own site, webflow.com, loads its WF Visual Sans from there. Framer lists framerusercontent.com among the domains it uses for "hosting assets, fonts, and design files" (Framer: Allowlist Framer domains). Shopify's theme platform hands developers a CDN URL for each font through its font_url filter (Shopify Liquid: font_url), and shopify.com itself serves its faces from cdn.shopify.com. For the visitor these are third-party hosts like any other - an extra origin, an extra connection, a request to a company that is not the site operator. For the site operator they are simply what the platform does; the fonts are theirs, the hosting is not. Anyone reading "third-party host" as "uses a font service" would overcount the latter.

What the data shows

Self-hosting is the norm in this set, not the exception. 1,503 of 1,836 sites (81.9%) serve at least one font from their own domain, and 1,106 (60.2%) serve every font that way. Third-party hosts are involved on 730 sites (39.8%), and the overlap between these two groups is exactly the 397 multi-route sites mentioned above. Among the dedicated font services Google dominates: 393 sites (21.4%) load at least one font from fonts.googleapis.com or fonts.gstatic.com, against 75 (4.1%) for Adobe Fonts. Given that our sample leans towards large brands with their own engineering, a fifth of them still on Google's hosts is the number we found most surprising.

The multi-route sites show how this happens. ycombinator.com self-hosts Avenir and pulls DM Sans, Source Serif 4 and Material Symbols from fonts.googleapis.com; zillow.com serves Inter and Ivar Headline from its own zillowstatic.com and Open Sans from fonts.gstatic.com; a16z.com combines an Adobe kit with an EB Garamond file from fonts.gstatic.com; and framer.com - the site of a company whose product hosts fonts - self-hosts its brand faces while referencing several Google files directly. A plausible reading is that the body face is a deliberate decision and the rest accumulates: a marketing page built on a different stack, an icon font, an embedded widget. We did not ask the operators, so that remains an interpretation.

The third-party hosts

The two Google hosts lead by a wide margin, and their counts are almost identical (456 and 450) because they are two halves of one route: a stylesheet reference on fonts.googleapis.com and the file references on fonts.gstatic.com that it produces. Adobe follows with 191 references on use.typekit.net. The Monotype entry is the cautionary tale of this ranking: 120 references from two sites. And the three platform CDNs together account for 225 references that have nothing to do with choosing a font service.

By country domain - and what this table cannot tell you

A widely repeated assumption says that German websites host their fonts themselves more often than others, because of the wave of warning letters that followed the Munich judgment of January 2022 (see the legal context below). We wanted to check that, so we split the sites by top-level domain. The table lists every domain ending with at least 20 sites and, for each, the share of sites that fetch at least one font file from Google's servers - fonts.gstatic.com or fonts.googleapis.com. A site that uses a Google typeface but serves the file itself does not count.

The direction matches the assumption. 9.7% of the 62 .de sites fetch a font file from a Google host, against 19.5% of the 1,131 .com sites - roughly half the rate. The two other European groups in the table point the same way: .nl at 9.1% and .fr at 13.6%, both below the .com figure.

That is where the honest reading stops, because the sample will not carry more. With 6 of 62 sites in the .de group, a two-proportion test puts the gap at p ≈ 0.056 - just outside the conventional five-percent threshold. A handful of sites either way would move the share by several points, and the .nl and .fr groups are smaller still at 22 sites each. So: the data lean toward the assumption, and they are not strong enough to confirm it. We would need a far larger German sample, drawn without the selection bias described in the method section, before anyone should cite this as evidence that German sites moved away from Google's servers.

One methodological note, because it changed our own answer. An earlier cut of this table counted sites using a typeface from Google's catalogue rather than sites loading fonts from Google's servers. On that measure German sites looked like heavier Google users, not lighter ones - because a site self-hosting Roboto, exactly the behaviour under discussion, counted the same as one loading Roboto from fonts.gstatic.com. The figures above are delivery-host based. The distinction decides the answer, which is a good illustration of why we publish the method alongside the numbers.

The Bunny zero

Not one of the 1,836 sites loads a font from fonts.bunny.net. Our scanner recognises the host explicitly, so this is not a detection gap. It is, however, a statement about this sample: large, mostly international sites with their own engineering teams, which - as the self-hosting figures show - tend to solve the problem Bunny Fonts addresses by hosting the files themselves. A directory of small German business sites might well look different. We simply have no data on that, and we would rather say so than extrapolate.

Weighing the routes

None of this yields a rule that fits every site; it yields a set of trade-offs that each site weighs differently.

Performance. Self-hosting removes two connection setups per visitor compared with the Google route and one compared with Adobe's, and since cache partitioning it gives up nothing in return. It also puts font-display, subsetting and preloading in the site's hands. Against that stands the operational work: a hosted service ships correctly subsetted woff2 files with sensible cache headers by default, and a self-hosting site that gets these details wrong can easily end up slower than it would have been on Google's CDN. web.dev's advice to measure both variants rather than assume is the honest answer here.

Data flows. With self-hosting, no third party sees the font requests. With every hosted route, the provider's servers receive a request - and thus the visitor's IP address - for every page view; what is retained and for how long is a matter of the provider's stated policy (Google's FAQ, Adobe's privacy notice, Bunny's no-logging statement), which we can quote but not verify. Platform CDNs sit in the same category, even though nobody picked them for their font hosting.

Licensing. For open-licence faces such as Google's catalogue the delivery route is a free choice. For commercial faces the licence terms decide which routes are available at all: some vendors tie web use to their hosted service and its usage reporting, others sell self-hosting licences. That is a contract question before it is a technical one.

Effort and control. A hosted service is one line of HTML and updates itself; the site operator gives up control over cache lifetimes, file formats and the moment a font changes. Self-hosting is the opposite trade. The multi-route sites in our data suggest that many teams make this choice per font rather than per site, whether deliberately or by accretion.

The legal context, as facts

Two events shaped the discussion about Google Fonts in Germany, and we reference them here as facts without assessing what they mean for any particular website. That assessment is legal advice, which this article does not give.

On 20 January 2022 the Regional Court of Munich I (Landgericht München I) ruled in case 3 O 17493/20 against the operator of a website that had loaded Google Fonts from Google's servers, thereby transmitting the visitor's IP address to Google without the visitor's consent. The court ordered the operator to stop the transmission and awarded the plaintiff 100 euros in damages. The published decision is available on the Bavarian state's legal portal.

On 21 December 2022, Berlin police executed search warrants against a lawyer and his client on behalf of the Berlin public prosecutor, on suspicion of attempted fraud and attempted extortion by warning letter in at least 2,418 cases, according to the police press release. The letters had been sent nationwide to private individuals and small businesses whose websites used Google Fonts. This is the "wave of warning letters" the self-hosting assumption above refers to.

Frequently asked questions

Check a site yourself

Paste any URL below to see every web font a page loads and the host it loads it from. If you are only interested in the Google question, the Google Fonts checker answers it directly; the DevTools guide shows how to read the same information in Chrome and Firefox; and the live font preview lets you try a replacement face on a page before you change anything.

Sources

• Google: Google Fonts CSS API, Technical considerations, Google Fonts FAQ
• Chrome: Gaining security and privacy by partitioning the cache (Chrome 86)
• Mozilla: Firefox 85 cracks down on supercookies (network partitioning)
• web.dev: Best practices for fonts
• MDN: font-display, unicode-range, rel=preconnect, Cross-Origin Resource Sharing
• W3C CSS WG: CSS Fonts Module Level 4 - font fetching requirements
• Adobe: Adobe Fonts, Adobe Fonts privacy notice
• Monotype: Hosting web fonts and reporting
• Bunny: Bunny Fonts, About Bunny Fonts
• Platforms: Webflow - Asset privacy, Framer - Allowlist Framer domains, Shopify - font_url filter
• Landgericht München I, judgment of 20 January 2022, 3 O 17493/20 (Bayern.Recht)
• Polizei Berlin, press release of 21 December 2022 on searches following the Google Fonts warning-letter wave
• Own measurements of 21 September 2026: scan database snapshot (1,957 sites); HTTP response headers of fonts.googleapis.com, fonts.gstatic.com and fonts.bunny.net

Site examples link to our profile of the respective site as scanned; the fonts and hosts named above are those recorded in that scan and may have changed since. All figures refer to the snapshot of 21 September 2026.