How to Self-Host Google Fonts

Google Fonts is the easiest path to web typography — paste a <link> tag, pick a font, done. But "easy" comes with trade-offs. Every time a visitor loads a page using the Google Fonts CDN, a connection is established to Google's servers (fonts.googleapis.com and fonts.gstatic.com). That connection takes time — a DNS lookup, a TCP handshake, a TLS negotiation — typically adding 100-300ms to the critical render path on first load. There's also a privacy dimension: those connections expose the visitor's IP address and the pages they visited to Google.

Self-hosting solves both problems. You download the font files once, serve them from your own server or CDN, and have full control over caching, subsetting, and delivery strategy. This guide walks through the complete process: obtaining the files, converting them to the optimal format, writing the CSS, and configuring your server.

Why Self-Host Google Fonts?

The performance argument for self-hosting has become more compelling as Google has tightened its caching policies. Until 2020, browsers could share cached copies of Google Fonts files across different websites — if a visitor had already loaded Roboto on one site, it was already in cache when they visited another. Google explicitly disabled cross-site font caching in response to privacy regulations, which eliminated that major historical advantage. Today, the Google Fonts CDN offers no cache-sharing benefit over a well-configured self-hosted setup.

On performance measured in practice, self-hosting from a server that's geographically close to your users can match or beat Google's CDN. If your infrastructure already uses a CDN like Cloudflare or Fastly, serving fonts through that CDN means your font files benefit from the same edge network as your other assets. This eliminates the extra DNS lookup and connection for a third-party domain entirely.

The GDPR dimension is increasingly non-negotiable for European users. German courts have found that embedding Google Fonts without user consent violates GDPR because it transmits the user's IP address to Google without a legal basis. The Landgericht Munich I ruling in January 2022 is the most prominent example, resulting in a €100 award against a website operator. While enforcement is uneven, the legal risk is real and self-hosting eliminates it entirely. When font files are served from your own domain, no third-party data transfer occurs.

Self-hosting also eliminates dependency risk. Google Fonts is free and reliable, but it's a third-party service outside your control. Outages, changes to the API, or policy changes can break font loading with no warning. Self-hosted files are entirely within your infrastructure's reliability envelope.

Step 1: Download the Font Files

The most straightforward way to obtain web font files from Google Fonts is through the Google Fonts download interface. Go to fonts.google.com, select the font you want — Inter, Roboto, Open Sans, or any of the 1500+ available families — and click the download button in the top right. This downloads a ZIP archive containing TTF or OTF font files, which you'll then convert to WOFF2.

A more targeted approach is the google-webfonts-helper tool by Mario Ranftl, available at gwfh.mranftl.com. This service lets you select a font, choose specific weights and character subsets, and download pre-generated WOFF2 and WOFF files directly, bypassing the conversion step entirely. It also generates the corresponding @font-face CSS. For most workflows, this is the fastest path to a self-hosted setup.

For programmatic workflows, Google exposes a CSS API that reveals the actual file URLs:

https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap

Requesting that URL returns a CSS file with url() references pointing to WOFF2 files on fonts.gstatic.com. You can extract those URLs and download the files directly. The files you get this way are already subset by Google — they're optimized for your requested character sets rather than the full Unicode range. Keep in mind that the URLs from the Google API are not guaranteed to remain stable, so treat them as one-time download sources rather than permanent links.

When downloading, be deliberate about which weights you need. Each weight is a separate file, and font files are not trivially small. Downloading four weights when you only use two means loading unnecessary data. Plan your type system first, identify the exact weight values you'll use in CSS, and download only those.

Step 2: Convert to WOFF2 Format

WOFF2 is the only font format you need for production web deployment. It uses Brotli compression (more efficient than the zlib compression in WOFF1) and delivers file sizes approximately 30% smaller than WOFF and 60-70% smaller than raw TTF. Browser support is universal across all modern browsers and covers 98%+ of global web traffic.

If you obtained TTF or OTF files from the Google Fonts download, convert them to WOFF2 before deployment. The best tool for this is woff2, the reference implementation from Google, available via most package managers:

# Install on macOS
brew install woff2

# Convert a single file
woff2_compress inter-regular.ttf
# → produces inter-regular.woff2

# Batch convert all TTF files in a directory
for f in *.ttf; do woff2_compress "$f"; done

Alternatively, FontTools — the most comprehensive open-source font manipulation library, written in Python — includes a WOFF2 converter:

pip install fonttools brotli
# Convert a file
fonttools ttLib.woff2 compress -o inter-regular.woff2 inter-regular.ttf

For a one-off conversion without installing tools, Cloud Convert and FontSquirrel's Webfont Generator both offer browser-based WOFF2 conversion. Squirrel's generator also performs subsetting and generates the @font-face CSS in one step, which is efficient for small projects.

Optional: Subsetting During Conversion

Subsetting reduces file size by including only the Unicode characters your site actually uses. A full-Unicode Inter font file might be 300KB as a TTF; the Latin-only subset that covers English and most Western European languages is around 70KB. The WOFF2 version of that Latin subset typically comes in at 20-30KB.

Using FontTools for subsetting:

pip install fonttools brotli

# Subset to basic Latin + extended Latin + punctuation
pyftsubset inter-regular.ttf \
  --output-file=inter-regular-latin.woff2 \
  --flavor=woff2 \
  --layout-features="*" \
  --unicodes="U+0000-00FF,U+0100-024F,U+0250-02AF,U+2000-206F,U+2070-209F,U+20A0-20CF,U+2C60-2C7F,U+A720-A7FF"

The --layout-features="*" flag preserves all OpenType features (ligatures, kerning, alternates) that might be referenced by CSS. Omitting it can break ligatures or kerning if you later enable those features.

Step 3: Write the @font-face CSS

With WOFF2 files in hand, you write the @font-face declarations that tell browsers where to find them. Each weight and style combination gets its own block. Here's a complete example for Inter at four weights:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter/inter-regular.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter/inter-medium.woff2") format("woff2");
  font-weight: 500;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter/inter-semibold.woff2") format("woff2");
  font-weight: 600;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter/inter-bold.woff2") format("woff2");
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

A few points on this setup. The font-display: swap value ensures users see text immediately in a fallback font rather than invisible text during the font load window. For the src, use a root-relative path (/fonts/...) rather than a relative path — this way the same CSS file works correctly regardless of which directory it's loaded from.

If you're using a variable font (a single file that covers the full weight range), the setup is simpler:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter/inter-variable.woff2") format("woff2");
  font-weight: 100 900;
  font-style: normal;
  font-display: swap;
}

The font-weight: 100 900 range syntax tells the browser that this single file covers the entire weight spectrum. You can then use any numeric weight value in your CSS rules.

For the complete reference on @font-face syntax and advanced options, see the complete @font-face guide and the how to import Google Fonts with CSS guide for comparison with the CDN approach.

Step 4: Configure Caching Headers

Font files are ideal candidates for aggressive caching. Unlike HTML, CSS, or JavaScript — which change with every deployment — font files are essentially permanent. The same inter-regular.woff2 file can be cached for a year or more without any risk that it will become stale.

The recommended caching policy for self-hosted fonts is a long max-age combined with immutable:

Cache-Control: public, max-age=31536000, immutable

max-age=31536000 sets a one-year TTL (in seconds). immutable is a directive recognized by modern browsers that tells them not to revalidate the resource even when the user manually refreshes the page — a significant performance optimization for frequently-refreshed pages.

In Nginx, add this to your server block or a separate location block matching font file extensions:

location ~* \.(woff2|woff|ttf|eot)$ {
  expires 1y;
  add_header Cache-Control "public, max-age=31536000, immutable";
  add_header Access-Control-Allow-Origin "*";
}

The Access-Control-Allow-Origin: * header is essential. Browsers enforce CORS for font files even when loading from the same domain, and without this header some browsers will silently fail to load the font.

In Apache, add to .htaccess or a <Files> directive:

<FilesMatch "\.(woff2|woff|ttf|eot)$">
  Header set Cache-Control "public, max-age=31536000, immutable"
  Header set Access-Control-Allow-Origin "*"
</FilesMatch>

For CDN-hosted fonts (Cloudflare, AWS CloudFront, Fastly), configure cache rules in the CDN dashboard to match these headers. Most CDNs will respect the Cache-Control headers from your origin server automatically once correctly set.

When you update a font file — switching to a new version of a typeface, changing your subset — use versioning in the filename or URL rather than overwriting the existing file. Since browsers will cache the old URL for up to a year, a URL like /fonts/inter/inter-regular-v4.woff2 or a hash-based URL ensures visitors always get the current version immediately.

Privacy Benefits: GDPR Compliance

Self-hosting eliminates every privacy-related concern associated with third-party font CDNs. When a browser loads a font from fonts.gstatic.com, it sends:

• The visitor's IP address (logged by Google)
• The Referer header, which includes the URL of the page being viewed
• User-agent information
• Standard HTTP headers that can contribute to browser fingerprinting

All of this happens automatically, without any action by the website visitor, and without the opt-in mechanism that GDPR's Article 6 requires for data processing that doesn't fall under a recognized legal basis. Google positions this data collection as necessary for the service, but regulators in several EU member states — particularly Germany and Austria — have concluded that using the Google Fonts CDN without user consent constitutes a GDPR violation.

Self-hosting completely eliminates this exposure. Font files served from your own domain generate no third-party network requests, transmit no visitor data to external parties, and require no consent mechanism. For any site with European visitors — which in practice means almost any public website — self-hosting is the legally cleanest path.

Beyond strict compliance, there's a more general principle: minimizing third-party dependencies reduces your attack surface and improves your ability to guarantee the behavior of your site. Self-hosted fonts mean your typography is not subject to sudden changes in Google's CDN behavior, API terms, or file availability. Combined with the performance benefits of a well-configured self-hosted setup — correct caching, a CDN that serves the same edge locations as your other assets, and no extra DNS lookups — self-hosting is the right choice for production websites at any meaningful scale.

There is also a broader philosophical point about web architecture worth noting. The more your site's correct functioning depends on third-party services — fonts from Google, icons from a CDN, scripts from analytics vendors — the more fragile the site becomes. Each dependency is a potential single point of failure, a privacy exposure, and a performance variable outside your control. Self-hosting fonts is one of the simplest steps in a broader move toward an architecture that you own and control end-to-end. The performance cost of that ownership is effectively zero with a properly configured CDN; the benefits in reliability, privacy, and operational confidence are real.

For the detailed technical steps on font-display behavior and how it interacts with self-hosted font loading, see the font-display strategies guide. For subsetting beyond the basic Latin approach described here, the font subsetting guide covers advanced subsetting strategies including glyph analysis tools and the unicode-range CSS descriptor.