Google Fonts & GDPR: How to Avoid an Abmahnung

Q: Is it now forbidden to use Google Fonts?

No. What's problematic is only the unannounced remote loading from a third-party server, because it transmits the visitor's IP without asking. You may keep using exactly the same fonts if you host the files yourself. The licences of most web fonts explicitly allow this.

The short answer first: the problem isn't the fonts themselves, but how they're loaded. If your website fetches a font directly from an external server when a page opens, every visitor's IP address is transmitted to that server in the process — usually without consent. Under the GDPR (the EU's data protection regulation, known in Germany as DSGVO), exactly that is considered legally risky, and in Germany it triggered a whole wave of Abmahnungen — formal cease-and-desist letters, typically sent by lawyers, demanding damages plus legal fees.

The good news: you don't have to change your fonts. You just have to serve them from your own server instead of someone else's. That takes about half an hour, and this article explains it step by step.

Note: this article is technical and general guidance, not legal advice. In concrete cases of doubt — for instance if you've already received a letter — consult a law firm specialising in IT law.

The 2-Minute Self-Test

Before you change anything, check whether you're affected at all. There are two quick ways:

Method 1 — search the page source. Open your homepage in the browser and press Ctrl + U (Windows) or Cmd + Option + U (Mac). The page source appears. Use Ctrl + F to search for these two addresses:

fonts.googleapis.com
fonts.gstatic.com

If the browser finds a match, your site loads fonts remotely — you're affected.

Method 2 — the Network tab in developer tools. Press F12, switch to the "Network" tab and reload the page. Filter by "font" or type the domain name into the search field. If you see requests going to third-party servers that deliver font files (.woff2, .ttf), you have your answer.

Important: run the test on the live site on the internet, not just a local preview. And check several page types — homepage, a subpage, the blog. Some website builders and theme plugins only load fonts in certain places.

Why This Is Legally Risky

The debate was set off by a much-cited ruling of the Regional Court of Munich I (Landgericht München I) from January 2022. The court held that dynamically loading Google Fonts from an external server transmits the user's IP address without their consent and thereby violates their right to informational self-determination. The claimant was awarded 100 euros in damages.

That's the verifiable fact. What happened next is more a matter of assessment: the ruling was followed by mass mailings of Abmahnung letters, often sent in bulk by individuals or law firms, demanding flat-rate damages and reimbursement of legal fees. Some of these campaigns were later classified as an abuse of rights by other courts, because they were plainly aimed at volume and income. But that removes neither the underlying problem nor the uncertainty for website operators.

In practice this means: the legal details are contested, the technical risk is not. Whoever stops the IP transmission has simply removed the point of attack — and no longer needs to worry about how future proceedings turn out.

The Solution: Host Fonts Locally

The core idea is simple: you download the font files once, put them on your own server, and load them via CSS. After that, the external request disappears — no visitor IP flows to third parties any more. Almost all common web fonts are published under free licences (OFL, Apache) that explicitly permit exactly this kind of self-hosting.

Step 1 — get the font files. Download the weights you need in the modern .woff2 format. Take only the weights you actually use (e.g. Regular 400 and Bold 700) — every extra file costs loading time.

Step 2 — upload the files. Put them in a folder on your server, for example /fonts/.

Step 3 — load them via @font-face. Add one block per weight to your stylesheet:

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

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

Then use the font as usual, for example:

body { font-family: 'BrandFont', system-ui, sans-serif; }

The font-display: swap; makes sure text is immediately visible in a fallback font instead of staying invisible until the file has loaded.

Step 4 — remove the external request. Search your HTML for the line referring to fonts.googleapis.com — usually a <link> tag in the head section — and delete it. The same goes for @import lines with that address in your CSS. If you skip this, the page loads the font twice: once locally and once, still, from the external server.

Step 5 — verify. Repeat the 2-minute self-test from above. No more matches for the two domains? Then the font part is done.

If you work with WordPress, a website builder or a theme, you often won't find the external request in your own HTML but buried deep in the theme or a plugin. Many themes now offer a setting like "load fonts locally" or "disable Google Fonts". Check for it — and test again afterwards, because not every setting delivers what it promises.

Think Further: It's Not Just the Fonts

Fonts are the best-known case, but not the only one. Every element that fetches something from a third-party server on page load transmits the visitor's IP in the process. Check the Network tab to see which other external domains your site contacts. Typical candidates:

External script libraries (e.g. JavaScript frameworks or icon sets loaded from a CDN) — these can almost always be self-hosted as well.
Embedded maps. A map service sitting directly in the page layout loads on every visit and passes the IP along. Alternative: a static map image with a link, or loading the map only after a click.
Video embeds. A video platform's player frame often opens a connection the moment the page loads. Better: load it only on click (a preview image instead of a live player).
Social media widgets and like buttons embedded as ready-made code.
External analytics and tracking services that fire before consent is given.

The rule of thumb: everything needed for the basic display (like fonts and scripts) belongs on your own server. Everything that passes visitor data to third parties (maps, videos, tracking) should only load after active consent — a cookie banner alone is useless if the content already loads before anyone clicks it.

For Us, This Is the Default

We build websites so that fonts are always served locally — not a single external font request on page load, in any project. That's not an extra you order on top; it's the starting point. The same logic applies to scripts and embeds: anything that would send visitor data to third-party servers is either self-hosted or not blindly embedded in the first place.

If you want to see what that looks like in real projects, you can run the test yourself in the showroom: open a site, press F12, check the Network tab — and see which external domains get contacted. The whole point of a portfolio is that you can verify it.

If you're thinking about a new or reworked website anyway: the articles on what a website really costs for a small business and why your business doesn't show up on Google cover budget and visibility. And if you're unsure whether your existing site is clean, have a look at the showroom and get in touch — a quick glance at the Network tab already tells you a lot.

Frequently Asked Questions

Is it now forbidden to use Google Fonts?

No. What's problematic is only the unannounced remote loading from a third-party server, because it transmits the visitor's IP without asking. You may keep using exactly the same fonts if you host the files yourself. The licences of most web fonts explicitly allow this.

Will I really get an Abmahnung if I change nothing?

There's no certainty either way — many of the mass letters were classified by courts as an abuse of rights, and not every site gets looked at in the first place. What is certain: as long as the IP transmission runs, the point of attack exists. Removing it costs little time and takes the issue off the table for good.

Is a cookie banner enough to fix the problem?

In most cases, no. Fonts and scripts typically load immediately when the page opens — that is, before the visitor has had a chance to click anything in the banner. By then, the transmission has already happened. The only effective fixes are to technically remove the external request (self-hosting) or to genuinely delay it until after consent.

I have a website-builder or WordPress site — do I still need to do anything?

Yes, often especially then. Many themes and plugins load fonts remotely by default, without it showing in your own HTML. Run the self-test and look in the settings for an option like "load fonts locally". Then test again to make sure the external request is really gone.

How do I know everything is clean after the switch?

With the same 2-minute test: neither the page source nor the Network tab should show any more matches for fonts.googleapis.com or fonts.gstatic.com — and in the Network tab, the font files should now come from your own domain.