Are Google Fonts GDPR-Compliant?

In late 2022, thousands of small business owners in Germany and Austria opened letters demanding a few hundred euros in "damages" because their websites loaded a font. The sites were ordinary: a bakery, a physiotherapy practice, a local architect. Each one embedded Google Fonts the standard way, with a link tag pointing at fonts.googleapis.com, and each one was accused of illegally sending visitors' IP addresses to Google in the United States. Many of those letters were later investigated as abusive, but the legal question underneath them was real, and it still shapes how careful developers load fonts for European audiences.

This article explains why Google Fonts became a GDPR issue, what the key court ruling actually said, how the EU–US Data Privacy Framework changed the picture, and the practical steps that let you keep using Google Fonts without exposing your site or your clients. It is a developer's guide, not legal advice; for a binding answer about your organization, talk to a data protection professional.

The Short Answer

The fonts themselves are not the problem. Almost every Google Font is released under the SIL Open Font License or Apache License, which allows you to download, self-host, and redistribute them.

The problem is how they are delivered. When a page loads fonts from Google's servers, each visitor's browser connects to Google and sends its IP address, user agent, and the referring page. Under the GDPR an IP address is personal data, so that connection is a transfer of personal data to a third party, made without the visitor's knowledge.

So the practical answer is:

How you use Google Fonts	GDPR risk
Self-hosted on your own server or CDN	Minimal; no data goes to Google
Bundled at build time (for example by next/font)	Minimal; the browser never contacts Google
Loaded from fonts.googleapis.com without consent	The setup the 2022 Munich court ruled against
Loaded from Google only after explicit consent	Lower, but awkward and bad for performance

Self-hosting is the answer most developers settle on, and it happens to be faster as well.

Why an IP Address Matters

The GDPR applies to any information relating to an identifiable person. In the 2016 Breyer judgment, the Court of Justice of the European Union held that even a dynamic IP address can be personal data for a website operator, because there are legal means to link it to an individual. That reasoning is the foundation of every Google Fonts complaint.

When you embed fonts from Google's CDN, this is what happens on each page view:

1. The browser requests the stylesheet from fonts.googleapis.com.
2. The stylesheet points to font files on fonts.gstatic.com, which the browser then requests.
3. Each request carries the visitor's IP address, the user agent string, and typically the Referer header showing which page they are on.

Google states that the Fonts API does not set cookies and that it limits data collection to what is needed to serve fonts. That reduces the privacy impact but does not change the legal analysis: you, the site operator, caused the visitor's personal data to be disclosed to a third party, so you need a lawful basis under Article 6 GDPR.

The 2022 Munich Ruling

The decision that started it all came from the Regional Court of Munich I (Landgericht München I) on 20 January 2022, case number 3 O 17493/20.

A visitor sued the operator of a website that loaded Google Fonts from Google's servers. The court found that:

• The visitor's IP address was transmitted to Google without consent.
• The operator could not rely on legitimate interest (Article 6(1)(f)), because the same fonts could be used without contacting Google, by self-hosting them.
• The transfer violated the visitor's right to informational self-determination, and the visitor had a feeling of discomfort about losing control of their data.

The court ordered the operator to stop and awarded €100 in non-material damages under Article 82 GDPR. The amount was small, but the reasoning was simple and easy to copy: if self-hosting is technically possible, sending data to Google for convenience is not justified.

The warning letter wave

Within months, a cottage industry appeared. Individuals used automated tools to visit thousands of websites, recorded which ones loaded Google Fonts remotely, and sent letters, sometimes via lawyers, demanding payment of around €100 to €170 to settle. German courts and prosecutors later pushed back on the most aggressive campaigns, treating visits made purely to manufacture claims as abusive, and authorities in Berlin opened criminal investigations into one of the best-known senders.

The lesson for developers is not that these claims were valid. It is that remote Google Fonts are trivially detectable and turned into an easy target. Removing them removes the target.

Did the EU–US Data Privacy Framework Fix This?

Partly. One strand of the argument against Google Fonts was that sending data to a US company was an unlawful third-country transfer under Chapter V of the GDPR, after the CJEU invalidated the Privacy Shield in the 2020 Schrems II ruling.

On 10 July 2023 the European Commission adopted an adequacy decision for the EU–US Data Privacy Framework (DPF). US companies that self-certify under the DPF, including Google, can receive personal data from the EU on the basis of that decision. In September 2025 the EU General Court rejected a first challenge to the framework, though further appeals and complaints remain possible.

The DPF addresses the international transfer question. It does not address the Munich court's core reasoning, which was about the lack of a lawful basis for disclosing the data at all. If self-hosting is easy, a court can still find that you had no legitimate interest in sending visitors' IP addresses to Google. So the DPF lowers the risk without making remote Google Fonts the safe default.

The Practical Fix: Self-Host Your Fonts

Self-hosting removes Google from the request path entirely. The browser fetches fonts from your domain, so no visitor data goes anywhere it would not already go.

The steps, in brief:

1. Download the font families you use, in WOFF2 format, with only the weights and subsets you need.
2. Put the files on your own server or CDN.
3. Replace the Google stylesheet link with your own @font-face rules.
4. Remove any preconnect hints to fonts.googleapis.com and fonts.gstatic.com.

A self-hosted declaration looks like this:

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

body {
  font-family: "Inter", system-ui, sans-serif;
}

The full walkthrough, including where to download files and how to subset them, is in how to self-host Google Fonts for better performance and privacy.

Framework and CMS shortcuts

• Next.js: next/font/google downloads Google Fonts at build time and serves them from your own domain. The browser never contacts Google. See how to use next/font in Next.js.
• WordPress block themes: the Font Library, available since WordPress 6.5, installs Google Fonts into your uploads directory so they are served locally. For classic themes, see how to add a custom font to a WordPress website.
• Privacy-focused CDNs: services such as Bunny Fonts offer a drop-in replacement for the Google Fonts API that states it does not log visitor IP addresses. That moves the trust to a different provider rather than removing the third party, so self-hosting is still the cleanest option.

Finding Hidden Google Font Requests

Removing the obvious link tag is often not enough. Themes, page builders, plugins, and embeds load Google Fonts on their own.

Check in the browser

1. Open the site in an Incognito window, with DevTools open on the Network panel and Disable cache ticked.
2. Reload and type fonts.g in the filter box. Any request to fonts.googleapis.com or fonts.gstatic.com is a remote Google Font.
3. Click each request and check the Initiator column to see which stylesheet or script triggered it.
4. Repeat on several page types: home, blog post, contact page, checkout.

Search the codebase

grep -rnE "fonts\.(googleapis|gstatic)\.com" ./src ./public ./wp-content/themes ./wp-content/plugins 2>/dev/null

Look for CSS @import statements, link tags, inline <style> blocks generated by page builders, and JavaScript loaders such as Web Font Loader.

Common hidden sources

• Google Maps embeds, which load Roboto from Google.
• YouTube embeds, which load fonts and other resources from Google domains.
• reCAPTCHA, which loads its own resources from Google.
• Page builders and premium themes that register Google Fonts by default even when you select a local font.
• Email signup and chat widgets that ship their own font stacks.

Embeds like Maps and YouTube involve more than fonts, so they usually belong behind a consent step or a click-to-load placeholder regardless.

Enforce it with a Content Security Policy

Once fonts are self-hosted, a CSP keeps them that way. Start in report-only mode, which logs violations in the browser console without blocking anything, to catch what you missed:

Content-Security-Policy-Report-Only: font-src 'self'; style-src 'self' 'unsafe-inline'

When the reports are clean, switch to the enforcing header:

Content-Security-Policy: font-src 'self'; style-src 'self' 'unsafe-inline'

Any future plugin or embed that tries to pull fonts from Google is blocked and shows up in the browser console. Tighten style-src further if your setup allows it.

What About Consent Banners?

You could keep loading fonts from Google and ask for consent first. In practice this is a poor option:

• Fonts are needed on the very first paint, before the visitor has interacted with a banner.
• Visitors who decline see your fallback font forever, so you are maintaining two typographic experiences.
• Consent management for something as basic as typography adds friction and complexity.

Consent makes sense for genuinely third-party features like analytics or embedded videos. For fonts, self-hosting is simpler, faster, and removes the question. The same reasoning applies to other Google services; our guide to Google Analytics and GDPR covers the consent side for analytics.

Performance Is a Bonus, Not a Trade-off

Some developers worry that self-hosting gives up the "shared cache" benefit of Google's CDN. That benefit no longer exists. Since 2020, Chrome, Safari, and Firefox partition their HTTP caches by top-level site, so a font cached while visiting one site is not reused on another. Loading from Google means extra DNS, TCP, and TLS work for two additional origins on every first visit.

Self-hosting typically makes fonts arrive sooner, especially when you combine it with a preload for the critical file. You get better privacy and better performance from the same change.

Licensing Is Not the Obstacle

Google Fonts are open source. The SIL Open Font License explicitly permits embedding, self-hosting, and redistribution, as long as you do not sell the fonts by themselves. Check the license file that comes with each family, but in nearly all cases nothing stops you from hosting the files yourself.

Google Fonts and GDPR FAQ

Conclusion

Google Fonts became a GDPR issue not because of the typefaces but because of the delivery: loading them from Google's servers sends every visitor's IP address to a third party. The Munich court ruled in 2022 that this was unjustified when self-hosting was an easy alternative, and while the EU–US Data Privacy Framework has since eased the international transfer concern, it has not changed that core reasoning.

The fix is straightforward and pays for itself. Self-host the fonts in WOFF2, remove every remote request including the ones hidden in themes and embeds, and lock it in with a Content Security Policy. You remove the legal risk, you remove an easy target for warning letters, and your fonts load faster because the browser has fewer origins to connect to.

Here are some useful references for going deeper on Google Fonts and GDPR:

1. Google Fonts: Privacy and data collection FAQ — Google's description of what the Fonts API logs and how the data is used.
2. GDPR-Info: Article 6 GDPR — the lawful bases for processing, including legitimate interest.
3. European Commission: EU-US data transfers — background on the EU–US Data Privacy Framework adequacy decision.
4. MDN Web Docs: Content-Security-Policy: font-src — how to restrict where fonts may be loaded from.
5. SIL: SIL Open Font License — the license most Google Fonts use, and what it permits.