How Websites Actually Deliver Their Fonts

Snapshot of 5 October 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. The first edition of this study (21 September 2026) rested on that static fetch alone. For this edition (5 October 2026) every site was additionally loaded in a real, rendered browser, and we read every stylesheet that is active once the page has loaded - which includes fonts added by JavaScript and fonts brought along by embedded third-party tools such as chat widgets, consent banners, newsletter pop-ups and payment buttons. Sites whose bot protection blocks the browser as well keep their static measurement. The browser does not interact with the page: a font that loads only after an interaction - after consent is given in a banner, or when a chat window is opened - is not captured, so the widget figures below are a lower bound rather than a complete count. For every font the scanner records the src of its rule - and that src names the host that actually delivers the font file. 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: 2,079 sites, as of 5 October 2026. For 1,939 of them the stored rule carried a usable source URL; every percentage in this article refers to those 1,939 sites unless stated otherwise. The delivery route of a site is read from the host of the first src URL of each of its non-fallback font rules, compared with the site's own registrable domain. A font whose file comes from that domain - relative URLs such as /fonts/… count as the site's own - counts as self-hosted; everything else counts as a third-party host. Google, Adobe and Bunny are recognised by their well-known hostnames.

The shift between the two editions has two reasons, both in the measurement rather than in the websites, and we can separate them. The first is the rendered pass. Evaluated with the first edition's rule, the second edition's data put "every font from the site's own domain" at 53.9% instead of 60.2%. Of the 1,106 sites the first edition counted as "own domain only", 129 have third-party font hosts in the rendered measurement (counted on 25 September; the same order of magnitude at this snapshot): 63 only because of Google Fonts loaded by JavaScript, 47 only because of other third-party hosts - mostly embedded widgets -, 12 for both reasons, and the remaining 7 because of font services or platform CDNs.

The second reason is the correction of an evaluation error that was already in the first edition. A protocol-relative font URL - //www.zillowstatic.com/…, without the https: - names a host like any absolute URL, but the first edition did not read it as one and counted such fonts as the site's own domain. Corrected, "every font from the site's own domain" falls further, from 53.9% to 51.8% - 42 sites. The first edition's self-hosting figures are therefore slightly too high. Its raw data are no longer available, so we cannot restate the first edition corrected; we can only say that the error pushed it in the same direction as the static fetch did. The first edition, in short, underestimated third-party delivery.

One more thing became clear while classifying: "self-hosted or CDN" is a false dichotomy. 569 of the 1,939 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, or a self-hosted brand face next to the typeface of an embedded chat widget. 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 on only 2 sites - two type-foundry sites, fontsmith.com and milieugrotesque.com - which between them declare 120 font references, because each lists many faces. Counted by references, as the first edition did, Monotype ranked among the most frequent hosts; counted by sites, as the ranking below does, it does not appear at all. That gap is the reason the ranking now counts sites.

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 shopify.com that is its own domain under our rule, the same registrable domain; for a merchant's shop on the platform the same host is a third party. For visitors of the sites that run on these platforms, the platform CDNs 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 still the norm in this set, but less exclusively than the first edition suggested. 1,573 of 1,939 sites (81.1%) serve at least one font from their own domain, and 1,004 (51.8%) serve every font that way - just over half, where the static measurement had put three in five. Third-party hosts are involved on 935 sites (48.2%), and the overlap between these two groups is exactly the 569 multi-route sites mentioned above. Among the dedicated font services Google dominates: 512 sites (26.4%) load at least one font from fonts.googleapis.com or fonts.gstatic.com, against 87 (4.5%) for Adobe Fonts. Given that our sample leans towards large brands with their own engineering, a quarter of them on Google's hosts is the number we found most surprising - and it was a fifth before the rendered pass added the fonts that scripts load.

Mixed setups show how this happens. ycombinator.com self-hosts Avenir and pulls DM Sans, Source Serif 4 and Material Symbols from fonts.googleapis.com; a16z.com combines an Adobe kit with an EB Garamond file from fonts.gstatic.com. zillow.com serves Inter, Ivar Headline and Object Sans from www.zillowstatic.com - referenced protocol-relatively, as //www.zillowstatic.com/…, the very pattern the first edition misread as the site's own domain - and Open Sans from fonts.gstatic.com. framer.com, the site of a company whose product hosts fonts, delivers its brand faces (GT Walsheim among others) through its own asset CDN framerusercontent.com and references several Google files (Geist and EB Garamond among others) directly. Under our rule the last two count as third-party only, because zillowstatic.com and framerusercontent.com are different registrable domains - the "domains, not companies" limit from the method section at work. 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

fonts.googleapis.com leads by a wide margin with 422 sites. fonts.gstatic.com, the host that Google's stylesheet sends the browser to for the font files, is recorded on 154 sites. The two are halves of one route, a site can appear under both, and taken together they are the 512 sites (26.4%) of the Google route above. Adobe follows with 87 sites on use.typekit.net - the same 87 as in the delivery table, since Adobe serves stylesheet and files from one host. Then come the three platform CDNs - Webflow with 29, Shopify with 15 and Framer with 13 sites - which have nothing to do with choosing a font service, and use.fontawesome.com with 16 sites, the hosted delivery of the Font Awesome icon fonts: a font service, but one that delivers icons rather than text faces. Hosts of embedded tools - chat widgets, consent banners and the like - are not in this ranking; they have their own section below. Nor is Monotype, with 120 references from 2 sites.

Fonts that arrive with a widget

The rendered pass surfaced a route the first edition could not see at all. 62 of the 1,939 sites receive at least one font through an embedded third-party tool - a chat widget, a consent banner, a newsletter pop-up, a payment button - that ships its own stylesheet and loads its typeface from the tool vendor's host. On 27 of those 62 sites these tools are the only third-party font hosts: the site itself serves every one of its own fonts from its own domain. Both counts are lower bounds - the browser does not click, so a tool that loads its font only once a chat is opened or consent is given is not in them.

The categories overlap - a site can embed more than one such tool - so the rows add up to more than 62. Examples are sites from our data on which the tool in that row loads a font.

As a measurement this says: a site that self-hosts its own fonts can still trigger font requests to third parties, through tools nobody thinks of as a font source. That consent banners are among those tools is the detail we found most notable. What any of this means for a given site depends on what the tool's vendor does with the requests, which is in that vendor's documentation, not in our data; we report the requests, not their consequences. A plausible reading is that the operators of many of these sites do not know those requests exist. We did not ask them, so that remains an interpretation.

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. 10.6% of the 66 .de sites - 7 sites - fetch a font file or stylesheet from a Google host, against 24.7% of the 1,199 .com sites, less than half the rate. The two other European groups in the table point the same way: .nl at 11.5% and .fr at 12.5%, both below the .com figure.

How much weight that carries is a matter of arithmetic, so here it is. With 7 of 66 sites in the .de group, a two-proportion z-test against .com puts the gap at p ≈ 0.009; in the first edition, with 6 of 62, it was p ≈ 0.056. That clears the conventional five-percent threshold - but the table looks at 6 domain groups, and what happens next depends on how one corrects for multiple comparisons: corrected for 6 comparisons (0.05 / 6 ≈ 0.0083), p ≈ 0.009 lies just above the threshold; corrected for 5 comparisons against .com (0.05 / 5 = 0.01), just below it. Add that the .de share rests on 7 sites, so a handful either way would move it by several points, that the .nl and .fr groups are smaller still at 26 and 24 sites, and that none of this is a random sample. So: the data point to German sites loading fonts from Google's servers less often than .com sites - they suggest it, they do not prove it. A larger German sample, drawn without the selection bias described in the method section, would be needed before anyone should cite this as proof that German sites moved away from Google's servers. And whether the wave of warning letters is the reason for the gap is a possible explanation, not something these numbers can show.

One methodological note, because it changed our own answer. An earlier cut of this table, in the first edition, 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,939 sites loads a font from fonts.bunny.net. Our scanner recognises the host explicitly, so this is not a detection gap, and the rendered pass - which added third-party hosts to 129 sites the static measurement had counted as own-domain only - did not change it. 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: scan database snapshot of 5 October 2026 (2,079 sites, rendered-browser pass); first-edition snapshot of 21 September 2026 (1,957 sites, static fetch); HTTP response headers of fonts.googleapis.com, fonts.gstatic.com and fonts.bunny.net, checked on 21 September 2026

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 site figures refer to the snapshot of 5 October 2026; the first edition of this article, measured 21 September 2026, is summarised in the box at the top.