Every time a browser loads a page that pulls a Google Font directly from Google’s servers, it sends that visitor’s IP address to Google as a side effect of rendering the text. In the US, there’s no single law naming Google Fonts, but the same third-party scripts and pixels that this kind of external call resembles are exactly what a growing wave of state wiretap lawsuits target. Self-hosting the font files instead removes the external call entirely, and it takes a fraction of the time an SSL certificate or a privacy policy update usually takes.
What actually happens when a font loads externally
A Google Font embedded the common way, through a link tag pointing to fonts.googleapis.com, triggers two separate requests: one for the CSS file listing the font’s styles, and another to fonts.gstatic.com for the actual font file. Both requests carry the visitor’s IP address, browser details, and the referring page, the same information any third-party script collects the moment it’s allowed to run. None of that data is required to render text on a page; it’s simply a side effect of loading the resource from someone else’s server instead of your own.
For a business serving US customers only, that’s a mild privacy footnote most sites never think about. For a business with any EU customers or visitors, it becomes a real question, since GDPR applies based on where the visitor sits, not where the business is incorporated, and a German court (Landgericht München I, case 3 O 17493/20, ruling of January 20, 2022) has already held that this exact setup violates GDPR because there’s no legitimate reason for the transfer. If you’re weighing hosting location and data transfer questions more broadly, Web Hosting and the Data Processing Agreement Your Small Business Needs covers that ground.
The broader US legal backdrop: third-party scripts under wiretap law
Google Fonts itself hasn’t been the target of US litigation the way it has in Germany. What has grown sharply since 2024 is a wave of lawsuits under state wiretap statutes, most notably California’s Invasion of Privacy Act (CIPA), against businesses running tracking pixels, session-replay tools, and chat widgets that quietly forward visitor data to third-party servers. The legal theory treats these third-party scripts as an unauthorized party “listening in” on a visitor’s interaction with the site.
Courts have been inconsistent about which third-party calls actually qualify. Several federal courts in California pushed back through 2024 and 2025, ruling that plain IP address logging and font or pixel requests don’t meet the technical definition of a “pen register” or “trap and trace device” under CIPA. That’s a meaningful limit on how far these suits reach, but it hasn’t stopped the filings, and it hasn’t settled the underlying question everywhere. The practical takeaway for a small business site isn’t “font requests are illegal,” it’s “every third-party call your site makes without a clear reason is a small, avoidable piece of exposure in a legal environment that keeps testing where the line sits.”
Why external loading became the default in the first place
Loading fonts from Google’s servers wasn’t an accident, it used to be a genuine speed advantage. Until around 2020, browsers shared the cache for resources like font files across different websites: if a visitor had already loaded a particular Google Font on one site, it sat ready in the cache and didn’t need to download again on the next one. That advantage is gone. Chrome partitioned its cache per visited site starting with version 86 in October 2020, Firefox followed with version 85 in January 2021, and Safari has isolated third-party resources this way since roughly 2013. Every browser now reloads the same Google Font separately for every website a visitor lands on, so the old performance argument for external loading no longer holds. What’s left is the privacy exposure, without the speed tradeoff that used to at least make it a reasonable default.
Dynamic loading versus self-hosting, side by side
| Dynamic (fonts.googleapis.com) | Self-hosted | |
|---|---|---|
| IP address sent to Google | On every page load | Never |
| Legal exposure | Documented GDPR violation in Germany; part of the broader third-party script pattern targeted by US wiretap suits | Removes the exposure entirely |
| Cache-sharing speed benefit | Gone since Chrome 86 / Firefox 85 | Not applicable, no external call |
| Setup effort | Usually the default, no action needed | A few minutes to a couple of hours, one time |
| Ongoing maintenance | Needs re-checking whenever a new font weight is added | None once the files are in place |
How to check if your site is affected
This takes about two minutes and doesn’t require any coding background.
- Open your website in a browser.
- Right-click anywhere on the page and choose View Page Source.
- Search (Ctrl+F or Cmd+F) for fonts.googleapis.com and fonts.gstatic.com.
- A match means the font is loading externally from Google’s servers.
- For a live check, open developer tools (F12), go to the Network tab, and reload the page. Any request to those two domains confirms the external load.
No match means either you’re not using Google Fonts at all, or they’re already self-hosted, and there’s nothing to fix here.
Self-hosting Google Fonts: the general approach
The fix changes where the font file lives, not how the page looks.
- Download the font files. Grab the font in WOFF2 format, either directly from the Google Fonts site or through a tool that packages the CSS and files together.
- Place the files on your own server. A dedicated folder like /fonts/ inside the website project is the common pattern.
- Write your own @font-face rule. Instead of pointing to fonts.googleapis.com, the CSS now references the local file, and every other style rule stays exactly the same.
- Remove the old Google links. Check the page head, theme settings, and any page builder for leftover references to fonts.googleapis.com, otherwise the font loads twice.
The exact steps differ by platform. WordPress and similar builders have plugins that automate the download and link rewrite, though it’s worth double-checking the result afterward. Hand-coded or statically generated sites, the kind Mr.Site builds, include the font files directly in the project and ship them at build time, with no external call at runtime at all.
Google Fonts is one example of a wider pattern
Google Fonts is a useful entry point because it’s easy to check and easy to fix, but it’s really a stand-in for a larger category: embedded YouTube videos, Google Maps widgets, chat tools, and analytics scripts all make the same kind of silent third-party call the moment a page loads. If you’re auditing your site for one of these, it’s worth checking the others in the same pass rather than treating each as a separate project, including whether your cookie consent banner already covers the tools that do need one. Removing several small external calls at once is also where the page-speed benefit becomes noticeable, since each one adds its own connection to a third-party domain before the page finishes rendering.
The next step for your business
Self-hosting fonts is one of those fixes that takes a few minutes and stays fixed, no ongoing tracking or consent logic to maintain afterward. Mr.Site runs several hundred business websites and handles this kind of technical privacy cleanup as part of ongoing managed website service, including a quick check of which other third-party calls your site is making without you noticing.