Google Fonts and GDPR: What the Rulings Actually Said

If you have searched for anything about Google Fonts and GDPR, you have probably read that a German court banned Google Fonts, that every website using them is exposed to 100 euro claims, and that the whole issue went away when the EU and US signed a new data deal. All three are wrong, and the third one is wrong in a way that could cost you.

Here is what the courts actually held, what changed since, what still applies today, and how to remove Google from your site properly. There is working code at the end.

What the Google Fonts ruling actually decided

On 20 January 2022 the Regional Court of Munich I decided case 3 O 17493/20. A website visitor sued the operator of a site that loaded Google Fonts the standard way, by linking to Google's servers so the visitor's browser fetches the font files directly. The court ordered the operator to stop passing the visitor's IP address to Google and awarded the visitor 100 euros.

Two things that judgment did not do. It did not ban Google Fonts, and it did not create a rule binding on anyone other than the parties. A Landgericht is a court of first instance. Its reasoning is persuasive and widely followed, but it is not a statute and it is not a decision of the Court of Justice.

The mechanism it identified, though, is real and worth understanding because it applies far beyond fonts. When your page tells a browser to fetch a resource from someone else's server, the browser opens a connection to that server. That connection carries the visitor's IP address, and usually a user agent string and a referrer telling the third party which page they were on. You do not send that data. Your visitor's browser sends it, because you instructed it to. No cookie is required and no tracking intent is required. It is how HTTP works.

Why the legitimate interest argument failed

This is the part that matters most, and it is the part that gets skipped.

The operator did not claim consent. They argued legitimate interest under Article 6(1)(f). The court rejected it on a narrow and rather devastating ground: Google Fonts can be used without any connection to a Google server at all. You can download the font files and serve them yourself. The visual result is identical. If the same outcome is achievable without disclosing the visitor's IP address to a third party, then disclosing it is not necessary, and an interest that can be satisfied by a less intrusive means does not outweigh the visitor's rights.

The court also dismissed the suggestion that visitors could protect themselves. A visitor is under no obligation to hide their own IP address, and expecting them to would invert the purpose of data protection law.

Notice what this reasoning depends on and what it does not. It depends on the existence of a readily available alternative. It does not depend on Google being American, on the adequacy of US law, or on anything Google does with the data once it has it. Hold on to that, because it is the reason the story does not end where most articles say it does.

The demand-letter wave, and how the courts killed it

What happened next is the part of this story that actually deserves to be famous, and almost nobody outside Germany knows it.

Through 2022, website operators across Germany began receiving letters demanding around 100 to 170 euros to settle a Google Fonts claim, citing the Munich judgment. They arrived in enormous volume. The operation behind the largest wave used an automated crawler to scan source code for the tell-tale Google Fonts link, then sent letters to every site it found.

German courts took that apart. In October 2022 the Regional Court of Baden-Baden ruled against the claims in case 3 O 277/22. In February 2023 the Ludwigsburg local court did the same in 8 C 1361/22. Then on 30 March 2023 the Regional Court of Munich I, the same court that had issued the original judgment, ruled in case 4 O 13063/22 that the mass claims were an abuse of rights under section 242 of the Civil Code.

The reasoning is worth quoting in substance. Someone who deliberately deploys a crawler to seek out infringements precisely in order to found claims on them is acting inconsistently with their own asserted grievance. Neither general personality rights nor the GDPR exist to provide people with a source of income from alleged violations of their own personality rights. Berlin prosecutors separately opened an investigation into the operation, including searches, over alleged fraud and extortion.

So the practical risk picture is not what the 2022 headlines implied. A genuine visitor with a genuine grievance has a claim that a German court has been willing to entertain. An automated shakedown does not, and if you receive a letter of that kind the correct first move is to check it against these rulings rather than to pay.

What changed with the EU-US Data Privacy Framework

In July 2023 the European Commission adopted an adequacy decision for the EU-US Data Privacy Framework. Transfers to US organisations that self-certify under it no longer need standard contractual clauses or a transfer impact assessment. You can check whether any given recipient is certified on the official Data Privacy Framework list.

That framework was challenged and survived. On 3 September 2025 the General Court of the European Union dismissed the annulment action in Latombe v Commission, case T-553/23, holding that the United States ensures an adequate level of protection for personal data transferred to certified organisations, that the Data Protection Review Court offers sufficient guarantees of independence, and that US bulk collection meets the essential equivalence standard from Schrems II given ex post judicial review.

Two caveats belong with that, and they are usually left out. The judgment was appealed to the Court of Justice on 31 October 2025 as case C-703/25 P, and it is the Court of Justice that struck down both previous transatlantic frameworks. Separately, the General Court expressly confined its assessment to the factual and legal situation as it stood when the adequacy decision was adopted in 2023, and declined to consider developments after that date. Adequacy currently stands. Treating it as permanently settled would be a third consecutive act of optimism.

Adequacy governs voluntary transfers. A separate question is how authorities compel data from a provider directly, which changed substantially in August 2026 and which we cover in our guide to the EU e-Evidence Regulation.

So is it fine now? No, and here is the reason

This is where the widely repeated conclusion breaks down, and it breaks down on a distinction that takes thirty seconds to explain.

GDPR asks two separate questions about the same act. First, do you have a lawful basis to process this personal data at all, under Article 6? Second, if the data leaves the EEA, is the transfer itself lawful, under Chapter V? These are independent. Passing the second does nothing for the first.

Adequacy answers the second question. The Munich judgment was decided on the first. Its holding was that there is no lawful basis to disclose the visitor's IP address to a third party when the same font renders perfectly well from your own server. That reasoning does not mention adequacy, does not depend on it, and is entirely unaffected by it. Self-hosting was the less intrusive alternative in 2022 and it is still the less intrusive alternative today.

There is a second reason the question is worth taking seriously beyond German case law. Under the ePrivacy rules as applied in most member states, and under GDPR generally, the safest treatment of any non-essential third-party call is prior consent. Which leaves you with a genuinely unattractive choice: gate your typography behind a consent banner and watch your page render in Times New Roman for everyone who declines, or spend twenty minutes self-hosting and stop having the problem. Self-hosting is also faster, so this is one of the rare cases where the compliant option and the good engineering option are the same option.

How to check your own site in two minutes

Do not assume. Themes, page builders, plugins and icon sets all pull fonts in without announcing it, and the call frequently sits inside a stylesheet rather than in your HTML.

The reliable method is your browser's developer tools. Open the Network tab, hard-reload the page, and filter for "google". Anything that appears is a request your visitor's browser made to Google. Do this on your homepage, on a content page, and on your checkout, because they often load different assets.

The fast method from a terminal, which catches the HTML but not calls buried in CSS or injected by JavaScript:

curl -sL https://example.com | grep -Eio '(fonts|ajax)\.(googleapis|gstatic)\.com[^"'"'"' )]*'

To catch imports inside your stylesheets, grep the files themselves:

grep -rn "googleapis\|gstatic" --include="*.css" --include="*.scss" --include="*.php" --include="*.html" .

How to self-host Google Fonts properly

Four steps. Budget twenty minutes.

1. Get the files. Download the family from the Google Fonts site, or use the google-webfonts-helper tool, which hands you woff2 files plus ready-made CSS for exactly the weights and character subsets you pick. Take only the weights you actually use. Every weight you download is a file your visitors have to fetch.

2. Serve them from your own domain. Put them somewhere sensible such as /fonts/ and declare them. One block per weight:

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

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

Keep font-display: swap. It shows fallback text immediately rather than leaving your page blank while the font loads. Use woff2 only unless you genuinely support browsers older than about 2016, in which case add a woff fallback.

3. Delete the old references. This is the step people skip, and a leftover preconnect still opens the connection. Remove all of these:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=...">

/* and inside your CSS: */
@import url('https://fonts.googleapis.com/css2?family=...');

4. Cache and preload. Fonts never change, so serve them with a long cache lifetime, and preload the one weight your page needs first to avoid a flash of fallback text.

<link rel="preload" href="/fonts/inter-400.woff2" as="font" type="font/woff2" crossorigin>

# nginx
location /fonts/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

On WordPress the fonts are usually enqueued by your theme or a page builder rather than sitting in a template you can edit, so you will need to dequeue the handle in your child theme, or use one of the plugins built to detect and localise font calls automatically. Verify with the Network tab afterwards either way, because plugins that promise this sometimes miss calls made by other plugins.

Fonts are rarely the only thing calling home

Once you have the Network tab open, the font is usually the least of it. The same legal analysis applies to every one of these, because the mechanism is identical: your page instructs the visitor's browser to contact a third party, and that contact carries their IP address.

Other Google endpoints: ajax.googleapis.com for jQuery and other libraries, which you can self-host the same way as fonts. www.googletagmanager.com and www.google-analytics.com, which are analytics and need consent regardless. maps.googleapis.com, which is worth deferring until a visitor actually clicks the map. reCAPTCHA, which loads from Google and is harder to remove because you need a replacement, though self-hosted alternatives exist. YouTube embeds, which at minimum should use the nocookie domain, and better still a click-to-load facade.

Everything else: icon fonts pulled from a CDN, chat widgets, embedded social buttons, hosted comment systems, and payment provider SDKs. Payment SDKs deserve particular attention, because they are commonly loaded on every page of a checkout regardless of which method the customer chose, which means a customer paying by one method still gets a connection opened to a provider they are not using. Load them when the method is selected, not on page load. For reference, we list every processor we use and how each one works on our payment methods page.

What we found when we audited our own site

We should be honest about how this article came about, because it makes the point better than a hypothetical would.

A reviewer assessing us for a privacy directory opened developer tools on packetra.com and found we were loading Inter from the Google Fonts CDN. We are a privacy-focused host. We write about exactly this. And a third-party font call had sat in our own head section anyway, because it came in with a theme and nobody had thought to look.

That is the actual lesson here, and it is not a legal one. These calls do not get added deliberately. They arrive inside themes, plugins, embed snippets and starter templates, and they survive because nothing on the page looks wrong. The only way to know what your site does is to watch the network requests it makes.

We self-hosted the font and audited the rest of the site the same way, which is also where the payment SDK point above came from. If you run one audit off the back of this article, make it the Network tab on your own checkout.

Frequently asked questions

Are Google Fonts illegal under GDPR?

No. Nothing prohibits the fonts themselves, which are open source and free to use. What a German court found unlawful was loading them from Google's servers without consent, because that discloses the visitor's IP address to a third party when a self-hosted alternative would achieve the same result. Self-host them and the issue disappears entirely.

Does the Munich ruling apply outside Germany?

It binds nobody outside its own case, and it is a first-instance German decision rather than a Court of Justice ruling. But GDPR is the same regulation across the EEA, and the reasoning it applied, that an interest achievable by less intrusive means does not justify the more intrusive one, is ordinary necessity analysis that any supervisory authority could apply. Treat it as a well-argued illustration of the general rule rather than as a local quirk.

Didn't the EU-US Data Privacy Framework fix this?

It fixed a different problem. Adequacy addresses whether a transfer out of the EEA is lawful. The Munich judgment turned on whether there was any lawful basis for the disclosure in the first place, which is a separate question under Article 6 that adequacy does not touch. The framework also remains under appeal at the Court of Justice.

I received a Google Fonts demand letter. What should I do?

Do not pay on receipt. German courts have repeatedly held that the mass-mailed versions of these claims, generated by crawling sites to find violations to complain about, are an abuse of rights, and the largest operation behind them drew a criminal investigation. Fix the underlying issue by self-hosting, keep the letter, and take advice on the specific claim rather than treating the demand as settled law. This article is general information, not legal advice for your situation.

Is self-hosting slower than the Google CDN?

Usually the opposite. The old argument for the CDN was that visitors would already have the font cached from another site, but browsers partition their caches per site now, so that benefit no longer exists. Self-hosting also removes a DNS lookup, a TLS handshake and a connection to another origin, all before your text can render.

Can I just put Google Fonts behind a consent banner?

You can, and it is defensible if the consent is genuinely freely given, informed and prior. It is also a poor trade. You take on a consent record-keeping obligation, and every visitor who declines sees your site in a fallback typeface. Self-hosting takes twenty minutes and removes the question rather than managing it.

The short version

The debate about Google Fonts and GDPR has been noisy out of proportion to the fix. A German court found there is no good reason to hand your visitors' IP addresses to a third party when you could serve the same file yourself. The adequacy decision that followed answered a different question and left that one where it was. The demand letters were largely an abuse of the ruling and the courts said so.

Underneath the legal argument is a plain engineering principle that outlasts any particular ruling: every third-party resource on your page is a connection your visitor did not choose to make. Serve what you can from your own server, load the rest only when it is genuinely needed, and check the Network tab occasionally to find out what your site is actually doing rather than what you believe it does.

Where your data physically sits is a related but separate question from who your pages talk to, and it is worth answering deliberately too. We cover that side in offshore hosting explained.