Self-Hosted Fonts and GDPR: Why Google Fonts Is a Liability in 2026
A 2022 German court ruling made loading Google Fonts from fonts.googleapis.com a billable GDPR violation. The fix is one afternoon of work — and your site gets faster as a side effect.
On 20 January 2022 the Munich Regional Court ruled (Az. 3 O 17493/20) that loading Google Fonts from fonts.googleapis.comtransmits the visitor’s IP address to Google without consent — a personal data transfer under GDPR Art. 4(1). The court awarded the plaintiff €100 in damages and confirmed the right to a future injunction. Within weeks, German law firms had filed thousands of pre-formed cease- and-desist letters at €170-€500 each.
Four years later the situation has not eased. Google Fonts on its public CDN is still a liability for any site with EU visitors, and every time a regulator or a competition lawyer goes looking for easy enforcement targets, this is the easiest one. The fix is also easy: self-host the fonts.
Why the CDN is the problem
When a browser requests a font file from fonts.googleapis.com, three things happen that GDPR cares about:
- The visitor’s IP address is sent to Google’s servers.
- The request includes the
Refererheader, exposing which page on your site the user is viewing. - The transfer crosses the EU-US border, which under Schrems II (CJEU C-311/18) requires explicit consent and additional safeguards.
None of these are problematic if the user has consented under your GDPR-compliant cookie banner. But Google Fonts is typically loaded from <head>on first paint — before the banner appears. That sequencing is what makes it a violation.
The same problem affects more than fonts
The court’s reasoning generalizes. Anything you load from a third-party CDN before consent has the same legal exposure:
- Google Fonts — the canonical example
- Adobe Fonts (Typekit) — same architecture
- Font Awesome CDN — same architecture
- jQuery / lodash / Tailwind from a public CDN
- Cloudflare-hosted scripts you did not configure yourself
- YouTube embeds (until the user clicks play)
The defensive default in 2026 is: serve everything from your own domain unless you have a documented reason and post-consent gating for the third-party fetch.
The fix for fonts, in one afternoon
- Identify the fonts you use. Your CSS already tells you. Note family, weights, styles.
- Download the woff2 files. Tools like google-webfonts-helper or Fontsource will package any open-licensed font (almost all of Google Fonts) into self-hostable woff2.
- Drop them in
/public/fonts/(or equivalent for your stack). - Replace the
<link rel="stylesheet">tofonts.googleapis.comwith@font-facedeclarations pointing at your own files. - Add
font-display: swapso the page renders immediately in a fallback font and switches when the custom font loads. - Preload the critical fonts. A
<link rel="preload" as="font" crossorigin>in the head saves one roundtrip on the fonts you use above-the-fold.
The performance bonus
Self-hosted fonts are usually faster than the Google CDN, not slower:
- No additional DNS lookup — one fewer round trip on first paint.
- No third-party connection setup — the TLS handshake to your own origin is already warm.
- You ship only the weights and subsets you actually use; the CDN ships entire family files.
- HTTP/2 push and preload work cleanly within a single origin.
Lighthouse LCP scores typically improve by 100-400ms after the switch on font-heavy pages.
What SOSEI does by default
Every site we rebuild ships self-hosted woff2 from a curated pool of 13 heading and 8 body fonts, all served from /fonts/ on the same origin as the page. No Google Fonts hotlink, no third-party font CDN, no consent banner needed for the fonts themselves. As a side effect, the rebuilt sites consistently load faster than their predecessors.
If you want to know whether your current site has thefonts.googleapis.com problem, run the free GDPR audit — we flag it automatically along with the other compliance gaps.