How many google fonts are there

External Google fonts on websites are in fact not usable

Categories: Data Protection, Bullshit Basics, Recommendations and Law

Many websites use external Google fonts. The fonts are then loaded from a Google server. This article shows that embedding Google Fonts in this way is problematic and actually impossible. The solution that is acceptable to most websites is simple.


In contrast to some of my previous posts, e.g. on cookies, the ePrivacy Directive or Consent Tools, the following information is not earth-shattering. The combination of technical and legal considerations as well as the technical solution options are hopefully halfway new. However, I had to find out that even a self-proclaimed data protection officer intentionally continues to use external Google fonts. I suspect that she is doing this either because she hopes for SEO effects (through the illegal integration) or because she does not know the solution mentioned below.

Incidentally, fonts other than those from Google are sometimes even more clearly subject to consent. For example, Fast Fonts (, because they use a tracking pixel for billing purposes.

Google fonts are also called Google Fonts designated. They are characterized by the fact that almost every font is supported and can supposedly be integrated into websites easily and without financial costs. If you integrate Google Fonts as Google suggests, you will Connections to Google servers built up.

Here is a real example of such a data transfer caused by integrated Google fonts:

As can be seen in the network log, two different domains are called at the same time, namely and or the associated subdomains.

I call this type of integration external Google fontsbecause they are loaded from Google servers. The situation is different if the fonts are loaded from your own server or a server of a provider with whom contractual guarantees have been concluded.

I decided to put this article in the Bullshit Basics category because many are still trying to look for all possible arguments why external Google fonts should suddenly be allowed.

What about data protection?

The integration of external Google fonts violates Article 5 Paragraph 1 GDPR. There is the principle of Data minimization called. This is opposed to any legitimate interest that allows certain data processing. The legitimate interest is defined in Article 6 GDPR. According to Article 5 Paragraph 2 GDPR, anyone who collects data must prove that they are complying with the principles of Article 5 Paragraph 1 GDPR (data minimization, etc.).

The violation occurs because it is easily possible to integrate Google fonts locally. All the required font files are simply downloaded, adjusted accordingly and then stored on your own web server. Local files can now be used on your own website. A data transfer to Google or other third parties no longer takes place.

Art. 25 GDPR requires technology to be designed in a manner that is friendly to data protection.

This shows that the legitimate interest is clearly ruled out. Nobody will get away with it in court. Should someone say otherwise, they either have no idea or are taking the wrong pills and suffering from excessive self-confidence.

What about cookies?

Usually no cookies are processed when retrieving Google fonts. However, I would like to point out that this can also be different. It is also sufficient if there is a single publicly accessible website worldwide that is in the domain of Google Fonts.

These types of websites abound, like a search for websites with the main domain proves:

Of these numerous existing websites, some set cookies on a domain that Google Fonts concerns. If a person calls up one of these websites and then a German website that loads external Google fonts, this German website violates the ePrivacy Directive. At least the operator of the website would first have to prove that the opposite is the case. I hope for him that he will then have the phone number of a very good contact on Google at hand.

I myself know of such websites that generate cookies, which then become relevant for Google fonts. Accordingly, Google writings also require consent based on Article 5 Paragraph 3 of the ePrivacy Directive in conjunction with the BGH judgment of May 28, 2020 - I ZR 7/16. In case of doubt, the operator of the website has to prove that Google does not use these cookies, which should be quite difficult and unbelievable. After all, these are so-called third-party cookies.

What about google?

In my opinion, numerous Google tools, without any exception, cannot be used in compliance with data protection regulations. Whether Google Tools are loaded with or without consent is another question. This is about them transparent, concrete naming of the mandatory information according to Article 13 GDPR.

In addition, Google itself admits to mixing data from your Google account, if you are logged in there, with the data collected when you call up Google Fonts. The data protection declaration that applies to Google Fonts states:

Accordingly, the following information about the Google tools used must be provided:

  • Purposes of data processing by the service provider
  • Data recipient
  • Risks, such as transfers to certain third countries or certain types of recipients, such as authorities or secret services
  • Purposes of cookies (these are generally only known to the service provider who, in the case of Google, usually does not reveal the purposes sufficiently

As you can easily see, this information cannot be made concrete, transparent and correct for Google Tools.

In addition, Art. 44 GDPR can always be cited for the Google Group, the data transfer to insecure third countries. However, I have got into the habit of only naming this problem subordinate, because the above data protection considerations are sufficient as a justification against external Google fonts.

Anyone who considers all of the above arguments for local and against external Google fonts to be invalid can certainly submit a contract that they have concluded with Google in order to receive suitable guarantees from Google for data processing in accordance with GDPR. Ideally, an opt-out option for collected data should then also be offered. Have fun!

Incidentally, the latter is communicated on the website of a provider of a consent tool, as well as the problem of using external Google fonts. It is all the more surprising that the website mentioned then uses external Google fonts itself. Since the fonts cannot be found on every subpage, and also not on the page with the article on Google Fonts, shows that the provider of the consent tool may not have done this on purpose and is overwhelmed with compliance with data protection requirements.

What about content delivery networks?

So-called CDNs offer fast, hopefully always available storage. The reason for using such systems is often a supposedly faster loading time for the website. So far, however, nobody has really been able to prove this to me (I don't want to rule out that this is the case, but I would like to have proof!).

It's debatable whether loading a small, static file from a CDN faster than from local storage. Browsers buffer requests of this kind, so that the local copy is often used for subsequent calls by the same user, which is the fastest of all.

If resources are loaded from CDNs, the browser can possibly parallelize loading processes by triggering the loading processes from several different servers almost simultaneously. This means that files from the local server can be loaded almost at the same time as files from other servers.

If you really want to use a CDN, you can do so. However, it must be ensured that the operator of the CDN is bound by the GDPR and of course also adheres to it. American companies are therefore ruled out as providers of CDN, unless they want to work with consent and accept a certain legal uncertainty.

By the way, you can also set up a CDN yourself. Apparently the operator of the website is so important that he needs a CDN. Then it should be possible to do so. After all, it is just a file server with a fast Internet connection. Such servers can be rented all over Germany.

No way you should in my opinion Cloudflare fall back because, according to my research, this provider cannot offer good data protection.

What is the solution?

Google Fonts can be integrated locally become. This can be done manually or with the help of a utility program. The utility is called Google Webfonts Helper. After calling up the tool's website, you can select a font in the left area (at least for desktop PC display). The finished files for local integration of the fonts can then be downloaded in the main area.

I would also like to describe the manual way here, also to clarify the basic principle.

For the manual route, download the font files. This is done as follows:

External fonts are loaded via a file like the following: This can be seen in the website's source code. Another possibility is the developer console of Firefox and other browsers, which can be opened with the F12 key. After the console opens, go to the website. The Network Analysis tab shows the Data transfers. There you will find loading processes from the domain and more.

Open the font file in the browser and copy the contents to a file named roboto.css (It makes sense to choose a different name for other fonts).

You will see lines that refer to external files. These look like this, for example:

src: url ( format ('woff2');

Usually only the sections that start with the comment are relevant / * latin * / are provided, possibly also those with an extended Latin character set / * latin-ext * /.

Download all files of this type. Change to roboto.css the specification so that it points to your local file. I don't see any indication in the Google Terms of Service as to why this should not be allowed.

From now on you can Save potentially incorrect data protection texts for Google Fonts. From now on, nobody can accuse you of forgetting the data protection text or of violating data protection rules with external Google fonts.

As you can see, the solution is relatively simple and not rocket science. It does not matter for data protection here that this procedure is best carried out by a tech-savvy person. If necessary, ask someone who is familiar with it. If he's good, he'll be able to do it in a very short time.

For WordPress websites, I recommend the use of design themes that either integrate Google fonts locally or provide an option for this.

Possible counter arguments and replies

The counter-argument of the supposedly longer loading times can be eliminated in the case of small font files, also based on my own years of experience with local fonts. If you want, you can use a data protection compliant CDN, but not the one from Google! It is also possible to set up your own CDN and is certainly worthwhile for websites that rely on a loading time that is five milliseconds shorter than local integration.

Below I have described a speed test that proves that external Google fonts do not bring any higher speed.

The argument that the fonts are no longer automatically (by Google) being repaired, is not one. After all, fonts should permanently look exactly as they were installed. That browsers change significantly once and a Font update would require is very rare. In the case of newly delivered fonts, it will seldom happen that the point on the i was forgotten. In the case of fonts that have been around for a long time, the question arises as to what should still be changed. It's about a font, not a nuclear reactor.

I know from my own experience that there is no maintenance problem. In addition, in other cases there are judgments according to which an entrepreneur with an online offer is obliged to regularly look at his offer and re-evaluate it. And the entrepreneur is even liable if a platform on which he advertises his products independently and fully automatically makes the offer of the entrepreneur illegal. Exactly the same commitment can be expected for writings (cf. for example OLG Frankfurt, decision of March 18, 2021, Az. 6 W 8/18).

Licensing So far, no one has been able to show me where it says that local integration, as I describe it above, is not permitted. On the contrary, the fonts run under the SIL Open Font License. Google marks all fonts on Google Fonts as open source and free:

Overview of the replies

Some are quite creative when it comes to somehow justifying the illegal use of external Google fonts. The following table shows a brief description of the alleged arguments and their response.

If you want to sleep soundly or want to do something for data protection or just want to comply with laws, then integrate Google fonts locally.

The attitude of regulators

In Germany there is a data protection supervisory authority for each federal state and, in addition, the federal data protection officer, who is responsible for public bodies, for example.

The statements made by regulators are opinions, viz Authority opinions. They can be used to create a Risk assessment to undertake. This can be used to estimate how likely it is to be fined by a supervisory authority. The legal question cannot be clarified in this way. Courts can take the opinions of authorities as a guide, but are in no way bound by them. In my experience, data protection authorities are generally more accommodating than courts. That doesn't help much if a warning from a private person or a competitor is pending.

Each state data protection officer may have a different opinion and recommendation. Here are two examples:

  • Bavaria: Allows external Google Fonts. Why is not clear to me (a reason is missing in the FAQ). Thankfully, the Bavarian authorities replied to me, and very quickly and comprehensively. The answer made it clear that data transfer to insecure third countries is viewed as critical and that external writings are allowed per se, but not in every case. Bavaria points out that data transfer to the USA without consent is only possible under the strict requirements of the Schrems II ruling.
  • Baden-Württemberg: There is no specific answer. Furthermore, the attitude of the authority is that data transfers to the USA are only not sanctioned if there is no alternative to the data transfer from the authority's point of view

Speed ​​test: local versus external Google fonts

For the comparison, the otherwise identical HTML page was tested once with external Google fonts and once with local Google fonts. The external Google Fonts were, as recommended by Google, with preconnect integrated so that a faster loading time is possible.

The online webpage test was used for the test. The test was carried out from a server in Frankfurt using the Chrome browser.

Test run with external Google fonts

The result shows in an overview the share of external fonts in the total loading time and the data transfer:

As you can see, the external Google fonts account for 15% of the total time of all inquiries that are required to access the website. The share of the transmitted data is 20.1% of the total volume.

In a waterfall diagram, the loading time for external Google fonts is shown as follows:

The relevant loading time, however, is the blocking time, i.e. the time that the retrieval with external Google fonts takes longer than it would be without these fonts:

The relevant loading times can be seen in more detail here:

The first request started at time 0.696 seconds. The last request ended at time of 0.699 seconds + 88 milliseconds (time to first byte) +26 milliseconds (content download) = 0.813 seconds

The relevant total loading time for the initial request for external Google fonts was 0.813 - 0.699 seconds = 114 milliseconds.

The follow-up call was evaluated in the same way. It was 91 milliseconds.

Test run with local Google fonts

The result shows in an overview the share of local fonts in the total loading time and the data transfer:

The proportion of the loading time with regard to all requests is so low with local Google fonts that I had to move the cursor over the red piece of cake. It is 12.8%.The share of the transmitted data is 18.3% of the total volume. However, the connection time is apparently not included here.

When first accessed, local Google fonts generate the following loading times:

The relevant loading time, however, is the blocking time, i.e. the time that the retrieval with local Google fonts takes longer than it would be without these fonts. A diagram according to servers as with external Google Fonts does not help here, because files other than fonts are also loaded from the server of the website.

The relevant loading times can be seen in more detail here:

The first request started at time 0.772 seconds. The last request ended at time 0.775 seconds + 270 milliseconds (time to first byte) +1 milliseconds (content download) = 1.046 seconds

The relevant total loading time for the initial access with local Google fonts was a total of 1.046 - 0.772 seconds = 274 milliseconds.

The follow-up call was evaluated in the same way. It was about as fast as the first call.

Speed ​​test result

The best way to see the result is to compare them.

External Google fonts are a little faster than local integration. If you look at the total loading time of the website, the following statistics arise (the total loading times are given as the denominator of the fractions, all data in milliseconds):

The total loading time with external Google fonts compared to locally integrated fonts was 3.8% faster when the website was accessed for the first time and 5.2% faster when the website was accessed again.

The optimization measures for my website have shown that the loading time can be improved much more effectively with completely different measures. Examples: caching at the file level htaccess activate, compress images further, deactivate unnecessary plugins.

By the way, the test took place with this website. Certainly it cannot be used academically because the number of tests is too small and the fluctuation in loading times is a few percent when there are several tests. Based on the results and the arguments and facts mentioned, everyone can make their own picture.

If you still rely on the speed argument for external Google fonts, you have to prove that

  1. a few milliseconds when the website is accessed for the first time are business-critical,
  2. no GDPR-compliant CDN is available (but that is still not an argument),
  3. its own CDN, too File server called, is not possible (that will be difficult to show),
  4. really all other measures have already been exhausted (good luck!)
  5. there is no data transfer to insecure third countries when accessing external documents
  6. Google does not use the traffic data received for its own purposes and does not pass it on to third parties (third parties are all who are unequal Google Ireland Ltd. are)

Load local fonts faster

If you include more than one font file (typical file extension: woff or woff2), which should include each font file separately and use non-blocking loading. The latter can be achieved as follows:

<link rel="stylesheet" href="font1.css" type='text/css' media="none" onload="if(media!='all')media='all'"><link rel="stylesheet" href="font1.css">

This line of code loads a font file in an asynchronous manner. This is ensured by the labeling media = ”none”. After the font file has been loaded, the media file is saved in the onloadEvent on media = "all" set so that the font is used for the current display.

The noscript-Instruction ensures that the font is loaded correctly even for browsers in which JavaScript has been deactivated.

Set up your own fast file server

You don't need one for your own website Content Delivery Network (CDN). A CDN is primarily necessary because a lot of websites are linked to it.

An own CDN, which is used for only a few of your own websites, can also be used as a quick File server describe.

Such a File server is a server with a fast internet connection and if possible without any restrictions regarding the data transfer volume. There are some offers from German providers that are very cheap. Anyone who needs a super-fast website (and also relies on it) can be expected to spend a few euros per month on a web hosting offer in order to be able to load the beloved Google fonts faster.

This was a post from the category Bullshit basics.
In this category, widespread untruths or false knowledge are thematized and processed with facts.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I came to data protection in 2017. Legal realities are no stranger to me. I try to get my results by looking at technology and law. In any case, that seems to me to be absolutely necessary when it comes to digital data protection. I would be happy if you subscribe to my newsletter.
Keywords for this article: