Self-hosted Google Fonts: the WordPress privacy upgrade you can ship in an afternoon.

Most WordPress themes load typography through Google Fonts, which is convenient — Google hosts the font files, the theme just references them. The convenience has a cost the theme builder rarely mentions: every visitor's browser hits Google's servers to fetch the font, and every fetch sends the visitor's IP address along with it. Under GDPR, that's a third-party data transfer that needs disclosure. Under the German interpretation, a court has ruled it actively requires consent. Under common sense, it's a third-party dependency that doesn't need to exist. Here's why it's worth fixing and what the fix actually looks like.

Open the network inspector on any WordPress site that hasn’t done this work, and you’ll see one or more requests to fonts.googleapis.com and fonts.gstatic.com in the initial page load. Those requests carry the visitor’s IP address. Google’s privacy policy on Google Fonts says the IP is used “for the purposes of the Google Fonts service,” but the disclosure is buried, the user never consented, and several European data protection authorities have taken issue.

The most consequential ruling: in January 2022, a Munich district court found that a site loading Google Fonts from Google’s CDN had transferred a visitor’s IP to Google without consent, in violation of GDPR. The court awarded the plaintiff €100. The amount was symbolic; the precedent was not. Lawyers in Germany started sending demand letters in volume, and “we use Google Fonts” became a real legal exposure for any site serving European visitors.

The fix is simple. Google Fonts are open-source. The font files can be downloaded and hosted on the same domain as the rest of the site’s assets. The visitor’s browser never sees fonts.googleapis.com again. The visual rendering is identical; the privacy footprint is removed; the consent question disappears for that surface.

How the standard Google Fonts integration works.

Most WordPress themes implement Google Fonts in one of two ways:

1. A <link> tag in the head pointing to [https://fonts.googleapis.com/css2?family=](https://fonts.googleapis.com/css2?family=).... The browser fetches the CSS, then fetches the referenced WOFF2 files from fonts.gstatic.com.
2. An @import url(...) in a CSS file.

Either way, two requests go to Google, both carrying the visitor’s IP. Caching helps after the first visit, but the first visit always pays the privacy cost.

What “self-hosting” actually means.

Self-hosting Google Fonts means the browser fetches them from your site’s domain (or its CDN), not Google’s. There are now two ways to achieve this, depending on your build:

1. The Native Way (WordPress 6.5+)

If your site uses a modern Block Theme or has theme.json support, the work is already largely done. You can use the native Font Library in the WordPress Site Editor:

• Navigate to Appearance > Editor > Typography.
• Browse the Font Library, select the Google Fonts you want, and click “Install.”
• WordPress automatically downloads the WOFF2 assets to wp-content/uploads/fonts/ and generates the necessary local @font-face CSS for you.

2. The Custom Theme Way (Classic/Bespoke Themes)

If you are managing typography strictly in code or using a classic theme, follow these steps:

• Download the fonts: Use a tool like Google Webfonts Helper to produce a package of WOFF2 files and the matching CSS. Select only the weights and subsets you actually use.
• Drop the files into the theme: Create a fonts/ directory in your theme. Place the WOFF2 files inside, and add the matching CSS to your theme’s stylesheet (or a dedicated fonts.css enqueued before the main stylesheet).
• Remove the Google requests: Strip the <link> to fonts.googleapis.com from the theme header, plus any @import statements. Confirm in the network inspector that no requests go to Google domains.

The performance bonus.

Self-hosting also reads as a performance improvement:

• One fewer DNS lookup: The request never leaves your domain.
• No third-party TLS handshake: Eliminates the latency of connecting to Google’s origin.
• Better cache control: Your CDN controls the headers, which are likely better optimized for your specific site than Google’s one-size-fits-all defaults.

The aggregate effect is typically a few hundred milliseconds off the Time to First Contentful Paint (FCP) on cold caches, which Core Web Vitals track and reward.

The implementation gotchas.

• The font-display strategy: Always use font-display: swap in your @font-face rule so the text renders in a fallback font during the brief load window.
• Subset only what’s needed: A site that only serves English can drop the Cyrillic, Greek, Vietnamese, and extended Latin subsets, cutting font payload by 50–80%.
• Preload critical weights: Add <link rel="preload" as="font" type="font/woff2" crossorigin> for the fonts used above the fold to ensure they start downloading immediately.

The license question.

Most Google Fonts are licensed under the SIL Open Font License or Apache 2.0, both of which explicitly permit redistribution. For the popular set—Roboto, Open Sans, Inter, Lato—self-hosting is legally identical to using them via Google’s CDN.

When this matters and when it doesn’t.

This matters when:

• The site serves European visitors (GDPR compliance).
• You are trying to minimize the consent-banner surface area.
• You care about Core Web Vitals for SEO.
• The site is a high-traffic ecommerce or lead-gen platform where every millisecond counts.

It matters less when:

• The site serves a strictly local/US-only audience and you are not prioritizing the privacy-by-default standard.

For any serious WordPress site, the work is small enough and the benefits real enough that it’s worth doing as a default. Self-hosted typography is one of those rare upgrades that is good for privacy, good for performance, and costs less than an afternoon. The right time to do it is whenever the theme is next under active development.

See Platform architecture built to last for how this looks as part of a broader practice.