Google Fonts License Guide: Apache 2.0, Commercial Use & Attribution

Are Google Fonts Actually Free?

Yes - unambiguously. Every typeface in the Google Fonts catalogue is released under an approved open-source license. Google does not charge for the fonts themselves, and it does not charge for traffic served through its CDN. There are no subscription tiers, no pageview limits tied to payment, and no hidden licensing walls that appear once you reach commercial scale.

The word "free" in this context carries two distinct meanings that both apply. First, zero cost: you pay nothing to download a font from Google Fonts, use it in a project, serve it on a website, or embed it in an application. Second, freedom: the open-source licenses grant you the legal right to use, modify, and redistribute the font files. This is the same philosophical definition used in software: free as in freedom, not merely free as in cost.

Every font on Google Fonts is reviewed by Google before being accepted into the catalogue. Part of that review is confirming that the license is a recognised open-source font license - either the SIL Open Font License (OFL) or the Apache License 2.0. Fonts released under restrictive or proprietary terms are not eligible. This means you can trust that any font you find on Google Fonts carries genuine open-source permissions, without needing to read legal text for each one.

The only meaningful limit on what you can do with Google Fonts relates to selling the font files as a standalone product. The OFL explicitly prohibits selling a font file by itself - though you can include it in a larger software product you sell. Apache 2.0 does not have this restriction. For the vast majority of designers, developers, and businesses, neither restriction is ever relevant.

If you have ever wondered whether the fonts you are using from Google Fonts are "really" licensed for your specific situation, the answer is almost certainly yes. The catalogue was built specifically to give designers and developers a reliable, legally clean source of typefaces for every kind of project.

Apache 2.0 vs OFL on Google Fonts

Google Fonts uses two open-source licenses. The SIL Open Font License (OFL) is by far the most common - it covers the overwhelming majority of fonts in the catalogue. Apache License 2.0 appears on a smaller number of fonts, most notably Roboto and several of its variants. Both licenses allow commercial use, web embedding, modification, and redistribution. For most users, the practical difference is zero.

The distinction becomes relevant if you are building fonts rather than using them. The OFL requires that derivative works - fonts created by modifying an OFL original - must themselves be released under the OFL. You cannot take an OFL font, modify it, and release it under a proprietary or restrictive license. Apache 2.0 has no such requirement: derivatives can be released under any license, including proprietary ones, provided you comply with attribution requirements in the Apache license itself.

The OFL also contains the Reserved Font Name (RFN) concept. If a font designer has declared certain names reserved, you cannot use those names for a modified version. For example, if you modify Inter, you cannot release your modified version as "Inter" - you must give it a new name. This protects the original designer's brand while still allowing broad modification rights.

You can verify the license for any specific font by visiting its page on fonts.google.com, scrolling to the bottom, and clicking the license link. Google also provides the license file inside every downloaded font ZIP. The file is typically named OFL.txt or LICENSE.txt.

If your only concern is whether a font can be used commercially in a website, app, or print project, neither license imposes any restriction. The OFL vs Apache distinction is a consideration for font developers creating derivatives, not for the typical designer or developer consuming fonts.

Commercial and Client Use

Commercial use of Google Fonts is fully permitted under both the OFL and Apache 2.0 licenses. There are no fees, no royalties, no special permissions required, and no paperwork to fill in. You can use any Google Font in any commercial context from the moment you add it to your project.

This covers a broad range of professional scenarios. You can use Google Fonts on a business website that sells products or services. You can specify Google Fonts in a brand identity project for a paying client and deliver the font files as part of a brand guide. You can embed them in a mobile app distributed on the App Store or Google Play, in a desktop application you sell, or in an e-book you publish commercially. You can use them in advertising - digital ads, print ads, outdoor signage, packaging, and broadcast materials. None of these uses require any additional licensing step.

There are no pageview limits or domain restrictions on Google Fonts under the open-source licenses. This is a meaningful advantage over commercial fonts that use tiered web licensing - you will never need to upgrade a tier because your site traffic grew. You can deploy the same fonts across an unlimited number of client projects and domains without purchasing additional licenses.

For agencies and freelancers, this means you can use Google Fonts as the typographic foundation for client work without any licensing handoff process. The client receives the full rights from the open-source license automatically - there is no transfer document, no sublicensing agreement, and no ongoing obligation between you and the client with respect to the font license.

One practical consideration for agencies: if a client requests a custom typeface based on a Google Font, the derivative must comply with the OFL (for OFL-licensed originals) - meaning the custom font must also be open-source. If the client wants to keep the customised font proprietary, the starting point should be a font with a more permissive license, such as Apache 2.0, or a commercial font that explicitly allows derivative creation. For a full breakdown of what agencies owe clients in terms of font licensing at project handoff, see our guide to client font licensing for agencies.

Attribution Requirements

Neither the OFL nor Apache 2.0 requires you to display visible attribution in your website, application, or product. You do not need to add "Font by [Designer]" or "Powered by Google Fonts" anywhere users can see it. There is no legal obligation to credit Google, credit the type designer, or disclose which fonts you are using in your front-end.

Attribution is only required when you redistribute the font files themselves. If you include a font in a software package, a design asset bundle, an open-source project, or any other distribution that passes the font files to someone else, you must include the original copyright notice and the license text. This is typically satisfied by including the OFL.txt or LICENSE.txt file alongside the font files in your distribution package.

For app developers bundling fonts with a mobile or desktop app, the standard practice is to include the license file inside the app's legal notices or acknowledgements section. Most platforms have a standard location for this: iOS apps use a Settings bundle, Android apps use an open-source licenses screen, and desktop apps include a licenses dialog or file. Including the license text there satisfies the attribution requirement for both OFL and Apache 2.0.

This is considerably simpler than commercial font licensing, where attribution requirements vary by foundry and license tier. With Google Fonts, the rules are consistent across the entire catalogue: no visible credit needed in your product, license text required only when redistributing the font files. For a broader comparison of how attribution works across all common open-source licenses including OFL, Apache 2.0, and Creative Commons, see the guide to open source font licenses.

Self-Hosting vs Google CDN

When Google Fonts launched, its CDN offered a meaningful performance advantage. Browsers could cache a popular font like Roboto from Google's servers and reuse that cached copy across every site that loaded it - meaning visitors who had already downloaded the font on one site would load it instantly on the next. This "shared cache" benefit was a legitimate reason to prefer the CDN over self-hosting in the early-to-mid 2010s.

That advantage no longer exists. Since Chrome 86 (released in October 2020), browsers partition their caches by site origin. A font cached from Google's CDN when loading one site is not reused when loading a different site. The cross-site cache sharing that made Google Fonts CDN performant was effectively eliminated as a privacy protection. Firefox and Safari made similar changes. Today, the CDN cache argument for using Google's servers instead of self-hosting fonts no longer holds.

Self-hosting now has clear performance advantages. Serving fonts from your own domain eliminates the additional DNS lookup required to resolve fonts.googleapis.com and fonts.gstatic.com. You gain direct control over HTTP caching headers, allowing you to set long max-age values and serve fonts over the same HTTP/2 connection as your other assets. You can preload the fonts you need with high precision, subset them to reduce file size, and serve them in WOFF2 format without relying on Google's automatic format negotiation. For a deeper look at the performance and licensing trade-offs between each approach, see our comparison of self-hosted fonts vs CDN delivery.

Tools like google-webfonts-helper and our own Webfont Generator simplify the conversion process significantly. You select the font family, choose the weights and styles you need, and download an optimised package ready to deploy. The entire self-hosting setup takes less than ten minutes for a typical project.

For existing projects using the Google Fonts API, migration to self-hosting is straightforward. Remove the Google Fonts <link> tag from your HTML, add self-hosted @font-face declarations, and upload the font files. The CSS font-family names remain the same, so no other CSS changes are needed.

Privacy Concerns and Legal Caveats

Using Google Fonts via the CDN means that when a visitor loads your page, their browser makes a request to fonts.googleapis.com or fonts.gstatic.com. That request includes the visitor's IP address. Google receives this IP address and can associate it with their other data collection - search history, signed-in account activity, advertising profiles. This is standard behaviour for any third-party resource request, but it has specific legal implications under the EU's General Data Protection Regulation.

In January 2022, a German court (the Munich Regional Court I) ruled that a website operator had violated GDPR by loading Google Fonts from Google's servers without user consent. The ruling found that transmitting a visitor's IP address to Google constituted a transfer of personal data to a third country (the United States) without an adequate legal basis. The website operator was ordered to pay €100 in damages and stop using the Google Fonts CDN.

This ruling is from a single German court and is not binding EU-wide, but it reflects a broader regulatory direction. Data protection authorities across the EU have consistently found that sending personal data to US companies requires either explicit consent or a valid transfer mechanism under GDPR. Loading Google Fonts from the CDN falls into the same category as Google Analytics, Google Tag Manager, or any other Google service embedded on a site - all of which have faced similar scrutiny.

The privacy issue is entirely avoidable by self-hosting. When you serve fonts from your own domain, no request is made to Google's servers and no IP address is shared. Visitors interact exclusively with your infrastructure. This eliminates the GDPR concern entirely and removes Google Fonts from your list of third-party data processors.

For organisations operating a consent management platform (CMP) or cookie banner, loading Google Fonts from the CDN without consent consent means the CMP needs to block the font requests until the user accepts. This can cause a flash of unstyled text (FOUT) on first visit - a poor user experience that self-hosting avoids completely.

Beyond GDPR, some enterprise clients and government organisations have security policies that prohibit loading any resource from an external domain. This is common in banking, healthcare, and government web projects. If you are building for these sectors, self-hosting is often a hard requirement regardless of privacy considerations. Checking client security requirements before committing to CDN-loaded fonts in the design phase avoids late-stage refactoring.