In January 2022, a regional court in Munich fined a website operator €100 — not for a data breach, but for a default setting: the site loaded its fonts from Google's own servers instead of hosting them locally. The ruling, case 3 O 17493/20, found that doing so sends a visitor's IP address to Google on every page load, and that counts as personal data under GDPR. No consent had been asked for it.
What makes the ruling worth checking against your own site isn't the amount, it's how common the setup is. The snippet Google itself publishes for using its fonts — a short <link> pointing at fonts.googleapis.com — was, by Google's own count around the time of the case, running on more than 50 million websites. Almost nobody chooses this as a deliberate data-sharing decision; it arrives as the default result of copying instructions Google wrote. GDPR doesn't care that it was copied rather than designed. It applies based on where a visitor is, not where the business or its hosting is registered — the same targeting rule we cover in more depth in our GDPR guide for international builds, and the reason this reaches a Malaysian or GCC-built site just as easily as a German one.
Why fonts specifically, and what actually fixes it
The court's reasoning was narrow, which is what makes it useful rather than alarming: the same fonts are available without contacting Google at all, so there's no legitimate-interest argument that survives the existence of a free alternative. Self-hosting means downloading the actual font files — released under an open licence that explicitly permits this — and serving them from the same server as everything else on the site, the way any other asset already is. Nothing about how the page looks changes. The one real difference is that the visitor's browser stops opening a separate connection to a Google domain, which happens to be one fewer third-party request on every page load — the same category of saving our CDN guide covers from the performance side rather than the privacy one.
When we scope a build for a client with international or EU-facing traffic, checking which third-party domains the page talks to by default — fonts, analytics, embedded widgets — is part of that initial review, not something raised after a complaint arrives. It takes a few minutes against a finished site, and it's a non-issue if it's caught before launch rather than after. It's also one more reason we keep hosting and domain ownership in the client's name from day one, including through our own managed hosting: the fewer services a site quietly depends on outside infrastructure the client actually controls, the fewer of these checks get missed later.
It isn't only fonts
Fonts are the example with a court ruling attached to it, but the same logic reaches anything a page loads from someone else's server before a visitor has made a choice about it — an embedded map, a chat widget, an analytics pixel, a video player. Each one is its own legal-basis question, not a single box to tick once. A site that passes a privacy review at launch can quietly fail it six months later when someone adds a new chat widget without re-asking that question, which is exactly why this belongs on the same recurring maintenance review as the rest of a site's dependencies, not a one-time audit done once and forgotten.
Frequently asked questions
Does this only affect businesses registered in the EU?
No. GDPR applies based on where a website's visitors are, not where the business or its hosting is registered — the same targeting rule covered in our GDPR guide for international builds. A Malaysian or GCC business with a public website that any EU visitor can reach is in scope the moment that visitor's IP address gets sent to a third party without consent.
Is it actually legal to self-host Google's fonts?
Yes. Google Fonts are released under open licences, mostly the SIL Open Font License, that explicitly permit downloading and serving the files yourself. Self-hosting isn't a workaround or a grey area — it's one of the two ways Google itself documents using the fonts, the other being the hosted API that caused the ruling.
Does the same issue apply to Google Maps, reCAPTCHA, or YouTube embeds?
The underlying question is the same — does loading this resource send a visitor's data to a third party before they've consented — but each one needs its own check rather than assuming the fonts answer covers it. Some, like an embedded YouTube video, have privacy-enhanced loading modes designed for exactly this; others don't have a self-hosted alternative at all, which makes consent the only lever available.
How is this different from needing a cookie consent banner?
A cookie banner is aimed at cookies — pieces of data a site asks the browser to store. Loading a font from Google's servers doesn't set a cookie by default, which is exactly why it's easy to miss: a site can have a fully compliant cookie banner and still be sending visitor IP addresses to a third party through an embed nobody thought to check.
Does a brand-new website have this exposure, or only old ones?
Any live site that loads fonts the default way has it, regardless of age — the court objected to the ongoing transmission happening on every page load, not to how the site was originally built. A site launched this month using Google's standard font snippet carries exactly the same exposure as one built in 2020.