You were asked to approve the look of your new website, and it looked great, so you said yes. Or maybe you spent hours building that site yourself, picking every font with care. Either way, here is a question you may not have asked: did you put your visitors at risk without meaning to?

Short answer: usually yes. When a website loads its fonts from Google Fonts the standard way, every visitor’s browser quietly requests those fonts from Google’s servers. That request hands Google the visitor’s IP address (the number that identifies their internet connection) and the page they are viewing, with no consent and no notice. The good news is the fix is simple, and you keep the exact same fonts.

Most websites pull their fonts from two Google addresses, fonts.googleapis.com for the styling and fonts.gstatic.com for the font files themselves. That means every visitor’s browser quietly hits Google’s servers before your page even finishes drawing. The visitor never agreed to that. You probably didn’t realize you agreed to it either. It is the kind of thing that gets baked in during design and never questioned again, whether you hired someone or did it yourself.

We learned this the hard way, on our own site

We are telling you this because it happened to us. Desk Ready makes a promise right on its home page: this site sets no cookies and loads no Big Tech trackers or fonts. So before launch we did a privacy audit, which means we opened the page and watched every request the browser actually made.

We found one we did not put there on purpose. Our theme was loading a font called Mulish straight from Google Fonts, through a single line buried in our custom styling. Every visitor would have pinged Google before they read a word. The exact promise we make on the page would have been false.

Here is the part that almost let it slip through, and the real lesson. On our own laptops the page looked perfectly clean. Our browser had a privacy shield turned on that silently blocked the Google request, so we never saw it. A normal visitor does not have that shield. On the live server, with no shield in the way, the request sailed straight through to Google. We only caught it because we checked the actual network traffic on the live site, not just “does it look fine on my machine.”

That is the trap. A font leak is invisible. It does not change how the page looks, it does not throw an error, and the person who built the site is often the least likely to see it, because builders tend to run the very privacy tools that hide it. You can approve a beautiful design, or hand-build one yourself, and ship this without ever knowing it is there.

The part most people get wrong

Here is the good news, and the thing almost nobody explains: the fonts are not Google’s. Popular faces like Mulish, Playfair Display, and Raleway are open-source, released under a free license (the SIL Open Font License) that lets anyone download and host them. Google Fonts is just one delivery service for fonts that are free to begin with.

So the fix is not “stop using the font you love.” It is “stop letting Google deliver it.” Your design does not change at all. The same letters render exactly the same way. The only thing that changes is who the visitor’s browser has to phone to get them.

How we fixed it (and what it actually took)

The fix was smaller than the problem sounds:

1. We downloaded the font once. Mulish is one modern font file, about 30 kilobytes, that covers every weight we use. We saved it onto our own server alongside the rest of the site.
2. We pointed the site at our own copy. A few lines of styling (a rule called @font-face, which simply tells the browser “here is the font and here is where to find it”) now load Mulish from our domain instead of Google’s.
3. We deleted the line that called Google. That was the actual leak. Once it was gone, nothing on the page reached out to Google at all.
4. We re-ran the audit to prove it. We checked the live page again with an automated tool: zero outside requests, zero cookies. The promise on our home page is now true, and we can show our work.

If you would rather not host the files yourself, there is a faster middle option. Bunny Fonts (fonts.bunny.net) is a privacy-respecting, European drop-in replacement: you change one word in your code, fonts.googleapis.com becomes fonts.bunny.net, and the visitor-tracking goes away. It is still an outside service, just an honest one that does not log or sell your visitors. We prefer hosting the files ourselves because it removes the outside service entirely, but Bunny is a genuinely good five-minute fix.

Why this is worth your time

• It is a promise to your visitors. They came to your site, not Google’s. Quietly handing their address to a third party is the kind of small betrayal that adds up to why people stopped trusting the web.
• It can be a legal problem. A German court ruled in 2022 that embedding Google Fonts violated privacy law, because it sent a visitor’s IP address to Google in the United States without consent. If you serve anyone in Europe, that exposure is real, not hypothetical.
• It is usually faster, too. Self-hosting means the browser talks to one server instead of detouring to Google’s, so the page can paint a touch sooner.

What to check on your own site

You do not have to be technical to ask the right question. Whether you built the site or paid someone to, you can ask your builder, or check yourself:

• “Does our site load any fonts from Google?” If the answer is yes, or “I’m not sure,” that is worth a look.
• Test it like a real visitor, not like a developer. The leak hides from the privacy tools that builders run. Check the live site with those tools off, or use an online scanner that lists every third-party request a page makes.
• Ask for the fix in plain terms: host the fonts on our own domain, or move to a privacy-first service like Bunny Fonts. Either way, the design stays exactly the same.

None of this requires giving up the look you chose. It just means the people who trust you with a visit are not quietly handed to someone else on the way in.