Google Fonts, the GDPR, and the German Court Ruling

A font ended up in front of a judge

On 20 January 2022, the Regional Court of Munich (Landgericht München I, case number 3 O 17493/20) ordered a website operator to pay a visitor 100 euros in damages. The reason: the site loaded Google Fonts dynamically from Google's servers, which sent the visitor's IP address to Google in the United States without consent. The court held that an IP address is personal data, that transmitting it to Google this way violated the visitor's rights, and that the transfer to the US, where the CJEU's Schrems II ruling found protection inadequate, made it worse. It awarded damages under Article 82 GDPR plus an injunction.

The award was small. The fallout was not. The ruling triggered a wave of mass warning letters (Abmahnungen) across Germany, with senders demanding roughly 100 to 170 euros per site from operators using hosted Google Fonts. Whatever you think of that campaign, and German courts pushed back hard on the abusive mass-mailing side of it, the underlying legal point stands: loading fonts from Google's CDN leaks visitor IPs to Google, and doing that without a legal basis is a GDPR problem.

What a hosted Google Font actually does

When your CSS contains something like @import url('https://fonts.googleapis.com/css2?family=Inter'), or your HTML links to fonts.googleapis.com, every visitor's browser connects to Google to fetch the stylesheet, then to fonts.gstatic.com to fetch the font files. Each of those requests carries the visitor's IP address, user-agent, and referring page to Google. It happens on page load, before any banner interaction, for every visitor. Unlike an analytics tag you can hold behind consent, a font the page needs to render is awkward to gate: block it and text either disappears or flashes in a fallback face, which is a poor experience.

That is what makes fonts different from most third-party embeds. You could gate them behind consent, but the result is ugly and fragile. There is a better answer that removes the legal question instead of managing it.

The fix: self-host the fonts

Download the font files and serve them from your own domain. Once the browser fetches fonts from your server instead of Google's, no visitor IP goes to Google, there is no cross-border transfer, and there is nothing to consent to. The font is now a first-party asset like any image on your site.

The steps are straightforward:

1. Get the actual font files (WOFF2 is what modern browsers want). Tools like google-webfonts-helper or the Fontsource packages produce the files and matching CSS for any Google Font, and the fonts stay under their open licenses.
2. Drop the files under something like /fonts/ on your own server or CDN.
3. Declare them with @font-face and remove every reference to fonts.googleapis.com and fonts.gstatic.com.

@font-face {
  font-family: 'Inter';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url('/fonts/inter-latin-400.woff2') format('woff2');
}

Set font-display: swap so text stays visible while the font loads. That is the whole change. Self-hosting also tends to be faster than Google's CDN, because you drop two extra DNS lookups and TLS handshakes to third-party origins, which helps the metrics in our guide on Core Web Vitals.

Find every Google Font call, including the hidden ones

Self-hosting only helps if you catch all the references. They hide in more places than the main stylesheet:

• Theme and page-builder settings that inject a Google Fonts link (common in WordPress themes and their plugins).
• Third-party widgets that pull their own fonts from Google.
• Inline @import statements buried in a CSS file.
• Icon-font or editor libraries that reference Google's CDN.

Search your codebase and rendered HTML for fonts.googleapis.com and fonts.gstatic.com, then confirm with the browser network panel that no request goes to either domain. A consent platform like CookieBeam surfaces these too: its scanner records outbound connections a page makes, so a connection to Google's font domains shows up in the inventory even when it is coming from a plugin you forgot about. That connection-level visibility is the difference between thinking you self-hosted and knowing you did.

The counterarguments, and why self-hosting still wins

You will hear a few objections. One is that Google Fonts are cached across sites, so returning visitors never re-download them. That stopped being true years ago: browsers now partition their HTTP cache by site precisely to stop cross-site tracking, so the shared-cache benefit is gone and self-hosting costs you nothing in load time.

Another is that a privacy-forward font CDN (Bunny Fonts and similar drop-in replacements) serves the same fonts without the Google connection. That is a real improvement over Google's CDN, but it still routes every visitor's request to a third party. Self-hosting keeps the whole thing first-party, which is the cleanest position to defend. A last objection is that the fonts in question are only icon fonts or Google's Material Icons, but those load from the same fonts.gstatic.com origin and leak the same IP, so they need the same treatment.

The takeaway

Google Fonts is the clearest example of a third-party asset that is cheaper to remove than to gate. Self-host the files, purge the Google references, and the IP leak that put a website operator in front of a Munich judge simply does not happen. You also get a small speed win for free.

If you genuinely cannot self-host in some corner of your stack, then the font load has to sit behind consent like any other non-essential third-party request, with all the visual awkwardness that implies. For most sites that is the harder road for no benefit. For the broader picture on US data transfers that made the Munich ruling bite, see our guides on EU-US data transfers and the biggest GDPR cookie fines, and for the French regulator's stance on third-party loads, our guide to the CNIL cookie guidelines.