A quick note first: this is a plain-language explainer, not legal advice. For your specific situation, have your own lawyer confirm the details. What follows is the technical picture and the fix, which is the part you can act on today.
What the fuss is about
Most websites use a nice typeface, and for years the easiest way to get one was Google Fonts. You paste one line into your site, and the font loads straight from Google's servers - fonts.googleapis.com and fonts.gstatic.com - every time someone visits.
That convenience is exactly the problem. To fetch the font from Google, the visitor's browser has to connect to Google, and that connection carries their IP address to a server in the US. It happens automatically, before the visitor has agreed to anything, and usually without the site owner even realising it. Under the DSGVO an IP address is personal data, and sending it to a third party in the US without a legal basis is a data protection problem.
The Munich ruling that started it
In January 2022 the Landgericht München I (Regional Court of Munich I) decided a case on exactly this point. A visitor sued a website operator because the site had embedded Google Fonts the remote way, passing the visitor's IP address to Google without consent. The court agreed this violated the visitor's rights and awarded the visitor damages.
Landgericht München I, 20 January 2022, Az. 3 O 17493/20
The court held that the automatic transfer of a visitor's IP address to Google, caused by embedding Google Fonts remotely without consent, was an unlawful interference with the visitor's personal rights, and awarded damages against the site operator.
One damages award to one visitor is small. What made this ruling matter was what happened next.
The wave of Abmahnungen
An Abmahnung is a formal cease-and-desist letter. In Germany a lawyer, a competitor, or a supposed affected person can send one demanding that you fix an issue, sign a penalty-backed declaration, and pay their costs. After the Munich ruling, the Google Fonts problem was easy to detect automatically - you just scan a site for a call to Google's font servers - and the ruling gave a ready-made template. Thousands of German site operators received letters, often demanding a payment of around 170 euros to make the matter go away.
So the risk is real. But here is the part the letters did not advertise.
Not every letter was legitimate
Many of the mass "pay 170 euros" letters were themselves legally dubious. When the same demand is blasted to hundreds or thousands of sites by automated scanning, courts and authorities have taken a dim view of it - it starts to look less like a genuine privacy grievance and more like a business model. Some of the senders behind these waves were investigated, and later letters of this kind were widely regarded as unenforceable. Several people simply ignored them on legal advice.
The takeaway is balance, not panic. The mass-mailing scam does not mean the underlying issue is fake. Remotely embedded Google Fonts without consent is a genuine DSGVO problem - the Munich court said so. The good news is that it is one of the easiest problems on the whole web to remove entirely, so you can take the target off your back regardless of who is sending letters.
The fix: self-host the fonts
The clean solution is to stop loading fonts from Google at all. Instead you self-host them:
- Download the font files (the modern
.woff2versions) once. - Put them on your own server, ideally EU-hosted, alongside the rest of your site.
- Reference them from your own stylesheet with a normal
@font-facerule. - Remove the old line that pulled the font from Google.
The site looks identical. The difference is invisible to visitors and total in effect: the font now comes from your server, so no visitor IP address is ever sent to Google. There is nothing left for a scanner to flag, and nothing to consent to. It costs nothing but a little build time, and most fonts on Google Fonts are open-licensed for exactly this.
The same logic covers the whole family of remotely embedded third parties. A Google Map, a YouTube video, a script pulled from a US CDN, a Meta or LinkedIn pixel - each one quietly contacts a third-party server and can hand over visitor data the instant the page opens. The pattern is always the same: either self-host it, or put a "click to load" consent gate in front of it so nothing loads until the visitor chooses.
How to check your own site in two minutes
You do not need any tools to see whether your own site has the Google Fonts issue:
- View the page source. In your browser, right-click the page and choose "View page source", then search (Ctrl/Cmd+F) for
fonts.googleapis.com. If it appears in a stylesheet link, your fonts are loading from Google. - Check the network tab. Open your browser's developer tools (F12), go to the Network tab, reload the page, and filter for
fonts.g. Any request tofonts.googleapis.comorfonts.gstatic.commeans visitor data is going to Google on every load. - No such requests? Then either your fonts are already self-hosted, or you are using system fonts - both are fine.
If you do find those requests, that is the single most common and most fixable warning trigger, and worth handling first.
How we handle it
Every site we build self-hosts its fonts by default. The font files sit on the same EU-hosted server as the site and are served locally - you can see it in this page's own source, where the fonts preload from /fonts/ rather than from Google. That means clients start DSGVO-safe on this exact point from day one, with nothing to retrofit and no warning letter waiting to happen.
Google Fonts is only one item on a short list of well-known issues that make a site an easy target. If you want the wider picture, read what "DSGVO-safe" actually means, or run through the DSGVO checklist before your next launch.