Google Fonts and the GDPR: what four in ten Baltic sites send to Google before the page draws

A web font has to come from somewhere. On a large share of sites it comes from Google’s servers, which means every visitor’s browser contacts Google before the page has finished drawing. The Baltic Web Audit, our near-census of the web in Latvia, Estonia and Lithuania in July and August 2026, counted how many sites do this. A German court has already ruled against the practice, and the fix is one of the smaller jobs on a website.

In short

About four in ten Baltic sites load their fonts from Google’s servers: 36% in Latvia, 42% in Estonia and 45% in Lithuania. Each visit to such a site sends the visitor’s IP address to Google before any consent could be given. In January 2022 the Munich Regional Court ruled that this breached a visitor’s rights under the GDPR, because the same fonts can be served from the site’s own server with no contact with Google. That is one German first-instance ruling, not EU-wide case law. But the fix it points to is small: host the font files yourself. You can check your own site in two minutes in the browser, and on a recent WordPress block theme you can make the change without a developer.

What the audit found

The audit’s browser loaded each homepage the way a visitor’s browser does and recorded where its requests went. The report’s scoreboard lists fonts loaded from Google’s CDN on 36% of Latvian sites, 42% of Estonian and 45% of Lithuanian.

What that means in practice is simple. The page’s code tells the browser to fetch a stylesheet from fonts.googleapis.com, and that stylesheet points to font files on fonts.gstatic.com. The browser makes those requests itself, directly to Google, and a server cannot answer a request without seeing the IP address it came from. The site owner never handles that address and usually never thinks about it. The visitor is not asked. This is also different from a cookie: there is nothing for a consent banner to hold back unless someone has wired the font stylesheet into the banner, and a page that changes typeface after the visitor clicks is a poor trade.

What the court actually decided

The ruling people refer to is the final judgment of the Munich Regional Court (Landgericht München I) of 20 January 2022, case 3 O 17493/20. A visitor sued a website operator because the site loaded Google Fonts from Google’s servers. The court decided three things that matter here:

• A dynamic IP address is personal data for the website operator, because the person behind it can in principle be identified with the help of the authorities and the internet provider.
• The visitor had not consented to the address being passed on, so the automatic transfer to Google was an unlawful interference with their rights.
• There was no legitimate interest to fall back on, and the reason is the useful part: in the court’s words, Google Fonts can be used without a connection to a Google server being made when the page is opened, and without the visitor’s IP address being transferred to Google.

The court ordered the operator to stop, to tell the visitor what data had been processed, and to pay EUR 100 plus interest.

It is worth being exact about what this is. It is one decision by one regional court in Germany, at first instance. It does not bind a Latvian, Estonian or Lithuanian court, and it is not a ruling of the EU’s Court of Justice. What carries across the border is the reasoning, because it rests on the GDPR, which is the same regulation in every member state: if a transfer of personal data can be avoided at almost no cost, it is hard to argue that you needed it.

WordPress took it seriously enough to change course. In June 2022 its Themes Team told theme authors that the decision “affects many themes in the directory” and recommended “switching to locally hosted webfonts”.

Why the font CDN no longer earns its place

The original case for loading fonts from Google was speed: so many sites used the same font files that a visitor would often arrive with the font already in their browser cache. Browsers ended that. Chrome partitions its HTTP cache from Chrome 86 onward, which means a file cached while visiting one site is not reused on another. Chrome’s own announcement names fonts as an example of the shared resources affected. So today each site’s visitors download the font from Google once per site anyway, and pay for an extra connection to a second server to do it.

Self-hosting is not automatically faster, and the honest version of the claim comes from Google’s own performance guidance. web.dev says that “on paper, using a self-hosted font should deliver better performance as it eliminates a third-party connection setup”, and that in practice the result depends on the site being served through a CDN and HTTP/2. A site on slow hosting that moves its fonts home carelessly can end up no faster. Done properly, self-hosting removes a third-party request and gives up nothing.

What you can check yourself, and what needs a developer

Three steps need no developer:

• See where your fonts come from. Open your homepage in Chrome, open DevTools (F12 on Windows, Option+Command+I on a Mac), go to the Network panel and reload the page. In the Filter box type domain:*.googleapis.com, then domain:*.gstatic.com; Chrome’s documentation describes the domain filter and its wildcard. A request to fonts.googleapis.com or fonts.gstatic.com means the fonts come from Google. An empty list on both means they do not.
• On a WordPress block theme, use the Font Library. WordPress 6.5 added a Font Library to the site editor, and the developer note for it says that “to allow sites to remain GDPR compliant, installing a Google Font downloads the file to the WordPress server”. Install the font you already use through it, select it in the theme’s typography settings, and the request to Google goes away.
• Check again in a private window. Repeat the first step after the change, with any cache on the site cleared. If the Google requests are still there, something else on the page is asking for them.

What needs a developer is everything outside that path. A classic theme or a page builder often has the Google link written into its templates or generated by its settings, and it has to be removed there. On a site that is not WordPress, someone downloads the font files, with a tool like google-webfonts-helper or the Fontsource packages, writes the @font-face rules and makes sure the files cover the characters your language needs, which for Latvian and Lithuanian means the extended Latin set. And when the Network panel still shows a Google font request after the theme is clean, the Initiator column says which script or stylesheet asked for it; tracing that back to a plugin or an embedded widget is developer work.

For a developer this is a short job, which is why we fold it into our cookie consent service instead of selling it separately: the same test that shows cookies set before consent shows the font requests too.

Why we can say any of this

The figures come from the Baltic Web Audit, which measured 293,806 of the 306,872 Baltic domains in its frame in one continuous run over July and August 2026, with every request carrying a user agent that named the study. The full method is in the report. The audit recorded whether a homepage loaded fonts from Google’s servers; it did not assess how any site justifies that request, and it names no site beside a weakness. Nothing here is a legal opinion on any particular site. Our own site serves its fonts from its own server: on 5 October 2026 the homepage of greenwiremedia.com contained no reference to fonts.googleapis.com or fonts.gstatic.com.

If you have looked at the Network panel and are not sure what you are seeing, send us the address and we will tell you where the fonts come from before anyone quotes for anything.