Munich Regional Court I, ruling of 20 January 2022 – €100 in damages per visitor. Since then, waves of cease-and-desist letters across Germany and Austria. The ruling triggered a broad discussion about the data protection implications of third-party integrations. Despite this, according to the HTTP Archive, over 40% of websites hosted in Germany still embed Google Fonts externally – a compliance risk that can be eliminated with minimal effort.

What Happens When Fonts Load

When a website embeds Google Fonts via fonts.googleapis.com, the visitor’s browser sends an HTTP request to Google servers on every page load. This request contains the user’s IP address, the User-Agent string (browser, operating system, device information), the Referrer (which page is being loaded), and potentially existing Google cookies. This data is transmitted to servers that are typically located in the United States.

From a data protection perspective, this constitutes a transfer of personal data to a third country. Since the Schrems II ruling by the CJEU (2020), the legal basis for such transfers has been significantly restricted. The EU-US Data Privacy Framework provides a new mechanism, but its permanence remains legally contested – particularly given political changes in the US since early 2025 that call into question the continued existence of the Privacy and Civil Liberties Oversight Board (PCLOB).

The Technical Chain in Detail

The data flow of a Google Fonts request is more complex than it appears at first glance. The browser first performs a DNS lookup for fonts.googleapis.com – depending on configuration, through a DNS resolver that itself collects user data. Then a TLS connection is established and the CSS file is loaded, which in turn references the actual font files at fonts.gstatic.com. This means: a single font import generates at least two external requests to two different Google domains.

Additionally, Google sets HTTP headers such as x-client-data, which can contain additional information about the browser state. In Chrome browsers, these headers may also include information about activated experiments (Field Trials). The overall picture is a data flow that goes significantly beyond what is technically necessary for delivering a font file.

Why Consent Alone Is Not Enough

Many websites attempt to legitimize Google Fonts through a consent banner. In practice, this rarely works reliably: the font request is often triggered before or in parallel with the consent banner, because fonts are needed for page rendering. Even with correct implementation, the question remains whether consent for a technically unnecessary third-country transfer can be based on Art. 6(1)(a) GDPR when a more privacy-friendly alternative (self-hosting) exists.

The principle of data minimization (Art. 5(1)(c) GDPR) argues against external embedding: if the same result – displaying a font – can be achieved without data transmission to third parties, the more data-economical variant is to be preferred. Several state data protection authorities have confirmed this assessment.

The DPF Risk

The EU-US Data Privacy Framework (DPF), which has provided a new adequacy decision as a successor to Privacy Shield since July 2023, rests on shaky ground. Its foundation – Executive Order 14086 – can be revoked by the US government at any time. Microsoft’s France president could not guarantee under oath that customer data would never be transferred to US authorities. Norway’s data protection authority already recommends exit strategies for US cloud services. Organizations relying on the DPF for Google Fonts are taking a regulatory risk that can be entirely eliminated through self-hosting.

Self-Hosting as the Solution

The technical solution is straightforward: Google Fonts can be downloaded and served from your own infrastructure. Services like Fontsource or the google-webfonts-helper tool automate this process. The steps include:

  • Downloading the required font weights in WOFF2 format
  • Creating the corresponding @font-face declarations in CSS
  • Integration into your own build process
  • Delivery via your own server or an EU-based CDN

Beyond GDPR compliance, self-hosting offers additional benefits: better performance by eliminating the DNS lookup to fonts.googleapis.com, full control over caching strategies, and the ability to perform targeted font subsetting.

Implementation with Fontsource

Fontsource provides Google Fonts as npm packages. Integration into a project takes three steps:

npm install @fontsource-variable/inter
@import '@fontsource-variable/inter';
body { font-family: 'Inter Variable', sans-serif; }

The font files are bundled into the build and served from your own server. No external request, no DNS lookup, no data protection issues. Fontsource supports over 1,500 fonts and offers both static and variable font variants.

Bunny Fonts as a Drop-in Replacement

For organizations that cannot or do not want to modify their build pipeline, Bunny Fonts (operator: BunnyWay d.o.o., data centers in the EU) offers a drop-in replacement. The migration requires only a domain swap:

<!-- Before -->
<link href="https://fonts.googleapis.com/css2?family=Inter" rel="stylesheet">

<!-- After -->
<link href="https://fonts.bunny.net/css?family=Inter" rel="stylesheet">

Bunny Fonts does not log IP addresses and does not set cookies according to its own documentation. All servers are located exclusively in the EU. As an interim solution, this is a pragmatic option – long-term, self-hosting remains the most sovereign approach.

Performance Benefits of Self-Hosting

Self-hosting improves not only data protection but also measurably boosts performance. Eliminating the DNS lookup to fonts.googleapis.com typically saves 50–150 ms. Eliminating the second request to fonts.gstatic.com saves an additional 30–80 ms. By serving from the same origin, fonts can also benefit from HTTP/2 multiplexing and load through the existing TLS connection without requiring a new handshake.

Combined with font-display: swap and preloading (<link rel="preload" as="font">), the Largest Contentful Paint (LCP) – a Core Web Vital – can be significantly improved.

Alternatives to Google Fonts CDN

Solution
Approach
GDPR-compliant
Effort
Google Fonts CDN
External embedding via googleapis.com
Problematic
Minimal
Fontsource
NPM packages, local embedding
Yes
Low
google-webfonts-helper
Download tool with CSS generator
Yes
Low
Bunny Fonts
EU-based CDN (AT), drop-in replacement
Yes
Minimal
Custom font pipeline
Download, subset, self-host
Yes
Medium
Adobe Fonts (Typekit)
External CDN, US servers
Problematic
Low

Key Takeaways

  • Every Google Fonts request transmits IP address, User-Agent, and Referrer to US servers – personal data under GDPR.
  • A single font import generates at least two external requests to two Google domains – the data flow extends well beyond font delivery.
  • The Munich Regional Court awarded damages in 2022 for embedding without consent – cease-and-desist waves followed in Germany and Austria.
  • The EU-US Data Privacy Framework rests on uncertain ground – relying on it is a regulatory risk.
  • Self-hosting is technically simple and improves both GDPR compliance and performance and caching control.
  • Fontsource delivers Google Fonts as npm packages – integration in three lines, no external requests.
  • Bunny Fonts (Austria) offers a GDPR-compliant drop-in replacement requiring no code changes.
  • Font subsetting reduces file size and eliminates unnecessary glyphs for unused language scripts.