The Google Fonts mistake that draws warning letters

Auditing this very website, we found the bug on ourselves. Two pages loaded their fonts through one line of CSS pointing straight at Google — which meant every visit sent the visitor's IP address to a server in the United States before anyone had agreed to a cookie banner. That exact pattern is what the Munich Regional Court ruled on in January 2022.

We are writing it up because it is the most common avoidable privacy defect on Austrian business websites, and because it takes about fifteen minutes to fix once you know what to look for.

Google Fonts is normally embedded so that the visitor's browser requests the font file directly from Google. For that request to work at all, the browser must hand over its IP address. Settled case law treats an IP address as personal data. So personal data is transferred to a third party — with no legal basis, no consent, and no way for the visitor to know it happened.

The Munich judgment (case 3 O 17493/20) awarded the claimant 100 euros. The amount was never the point. The point is what followed: waves of warning letters sent to website operators across the German-speaking market, typically demanding between 150 and 500 euros plus legal costs. For an SME with one website that is irritating. For an agency running thirty client sites it is an operational risk.

1. 01Open your site in a private window and deliberately do NOT accept the cookie banner.
2. 02Open developer tools (F12) and switch to the Network tab.
3. 03Reload the page and filter requests for "fonts".
4. 04If you see fonts.googleapis.com or fonts.gstatic.com, a request is leaving your visitor's browser before consent.
5. 05Repeat on subpages. The defect is often confined to a few pages — in our case it was exactly two.

Also search your source for the string "googleapis". It usually appears in a <link> tag in the head, in an @import at the top of a stylesheet, or — easiest to miss — inside an embedded <style> block in a single page component. That is precisely where ours was hiding.

The fix is to serve the font files yourself. Download them once, put them alongside your other assets, and declare them with @font-face. From then on the visitor's browser only ever talks to your server.

If you are on Next.js you get this for free: next/font downloads the fonts at build time, bundles them with your application and generates the @font-face rules for you. Not one request reaches Google at runtime. On WordPress, plugins such as OMGF or Local Google Fonts do the same job — but re-run the Network test afterwards, because themes and page builders love to load fonts a second time somewhere else.

The bug had a second, purely visual consequence that surprised us. Because the font declaration only loaded on two pages, the display typeface silently fell back to a system serif everywhere else. Twenty-one components were using a typeface that never arrived. The privacy defect and the design defect were the same defect.

That is the real lesson. A site built cleanly for privacy is almost always built more cleanly in general — fewer third-party dependencies, fewer requests, faster loads, and fewer places where something can break without anyone noticing.

”

“The request you never make is the only one you never have to document, justify or defend.”

• Run the Network test above on your home page and at least three subpages.
• Search your source for "googleapis" and "gstatic".
• Check the same pages for other third parties loading before consent: embedded maps, YouTube players, Adobe fonts, analytics scripts.
• Write the result down. A dated audit record is the difference between a letter you can answer and a letter that costs you.

If you would like a hand with the audit: we have been through exactly this on our own site, and we run the same check for clients across Burgenland, Vienna and the border region.