google/fonts: the binary font repository behind Google Fonts
Font files available from Google Fonts, and a public issue tracker for all things Google Fonts
At a glance
- What is it?
- The google/fonts repository holds the .ttf files served by fonts.google.com, split by license, with a METADATA.pb file per family. It is a distribution channel and an issue tracker, not a font editor or a build system.
- Who is it for?
- Adopt google/fonts if you need the actual .ttf binaries Google serves, want to self-host them through a tool such as Fontsource, or need to file a bug against a specific family. Do not adopt it as a source tree to edit: /axisregistry and /lang are git subtrees that must be changed upstream, and family files are generated from designer sources elsewhere.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What google/fonts actually is, and who needs it
The README opens with a blunt statement of scope: the project "mainly contains the binary font files served by Google Fonts". That sentence is the whole product. There is no build step, no font editor, no subsetting tool. If you want to change a glyph, this repository is the wrong place to start.
What it does solve is a distribution problem. Fonts on fonts.google.com are also files on disk, and those files need a canonical home that is versioned, forkable and auditable. Putting them in a git repository means a family's history is a commit log, an issue about a broken kerning pair can link to the exact file, and anyone can clone the whole collection instead of scraping a CDN. The audience is narrow and specific: people who need the binaries themselves (self-hosting, packaging for a Linux distribution, embedding in an application), people who want to report a defect in a font, and designers who want to see how a family is structured before they contribute one.
It is not a place to browse fonts visually. The README points readers at fonts.google.com for that, and the repository offers no preview, no specimen page and no search. You get directories and .ttf files.
License directories and the METADATA.pb file
The layout carries meaning. Top-level directories indicate the licence of everything inside them, and the repository ships with apache/, ofl/, ufl/ and cc-by-sa/. Family subdirectories are named after the family, and each one holds the .ttf files plus two companions: METADATA.pb, which the README describes as containing designer information, genre category and licence, and DESCRIPTION.en_us.html, a US English description of the family.
That convention is the useful part. A script that walks the tree can read the licence from the parent directory name and the family metadata from the .pb file without opening a single font. The trade-off is that the licence directory is a coarse signal. The README is explicit that you must "always read the license for every font that you use", and that each family directory contains its own licence file. The directory name tells you the licence family (OFL, Apache, UFL, CC BY-SA); it does not tell you whether a Reserved Font Name applies.
Two subtrees are explicitly off limits. /axisregistry and /lang are git subtrees, and the README says no changes should be made directly in this repository, because they are synced from github.com/googlefonts/axisregistry and github.com/googlefonts/lang. A patch sent here for either will not survive the next sync.
Downloading fonts from the repository and installing one
There is no installer. The README offers two ways to get the files: a ZIP snapshot of the whole collection at https://github.com/google/fonts/archive/main.zip, which it notes is over 1GB, or a git clone so that later updates only fetch what changed. For a single family, cloning is far cheaper than the ZIP.
The README points readers who are new to git at the illustrated guides on guides.github.com, the GitHub YouTube channel and the interactive learning site at skills.github.com. Once the collection is on disk, the family directories under ofl/ are the ones most people will look at first.
If you would rather not manage files by hand, the README names Fontsource as "one popular service" that offers bundled NPM packages, and fnt as a package manager for Linux, macOS, FreeBSD and HaikuOS that installs single fonts. For RPM and DEB based systems it links individual font repositories at bootes.ethz.ch. All of these are third-party projects; the README links to them rather than shipping them.
Where this repository stops being the right tool
The clearest limitation is that the repository is downstream of the actual font projects. The README states that source files for each family are "often available from the designer, or from github.com/googlefonts", and that these are usually collaborative projects. So a bug in a glyph, a missing weight, or a request for a new language coverage does not get fixed by editing the .ttf here. It gets filed as an issue and, if it moves, fixed upstream and re-synced.
That has a practical consequence for anyone treating the repository as a vendored dependency. Because there are no releases (the repository publishes none), there is no version number to pin against. You pin a commit hash or you track main. If you copy a family into your own project, you own that copy and its drift.
The size is the other constraint. The ZIP is over 1GB, and a full clone is not much smaller. Teams that need three families should not clone the collection; they should take the files they need, or use a package manager. The README's own framing (self-host "using a variety of third-party projects") concedes that this repository is a source of files, not a delivery mechanism.
Finally, the README does not document any rollback or deprecation procedure for families that leave the collection. The repository does contain to_delist.txt, to_production.txt and to_sandbox.txt at the top level, which suggests a staging workflow, but the README does not explain them.
Fontsource and fnt compared with cloning the repository
The README names two alternatives, and they solve different halves of the problem.
Fontsource takes the same font files and republishes them as NPM packages, so a web project installs a family with a package manager and imports its CSS rather than committing .ttf binaries. The difference in approach is that Fontsource versions each family as a package, which gives you a semver range and a lockfile entry. Cloning google/fonts gives you the whole collection at one commit with no per-family version. If your consumer is a bundler, Fontsource fits; if you need the raw files for a desktop application or a distribution package, it does not.
fnt is the opposite shape: a package manager for Linux, macOS, FreeBSD and HaikuOS that installs single fonts onto the system. It is for the case where you want one family available to every application, not bundled into one project. The README also links RPM and DEB repositories at bootes.ethz.ch for individual fonts, which covers the same need for those distributions. All three are third-party; the README links out to them rather than maintaining them, so their release cadence is unrelated to this repository's.
Maintenance, licensing and what the repository does not tell you
The repository is not archived, and its last push was on 2026-09-20. It carries a CI workflow (the README badge points at .github/workflows/ci.yml), which implies automated checks run against contributions. There are no releases, so there is no upgrade path in the usual sense: you either pull newer commits or you do not. The upgrade cost is therefore proportional to how much you copied. A project that vendored one family pays almost nothing to update; a project that mirrored the collection pays the bandwidth.
The licence position is more layered than a single repository licence, and the README is direct about it. Most fonts use the SIL Open Font License v1.1, some use Apache 2, and the Ubuntu fonts use the Ubuntu Font License v1.0. The OFL has an option for copyright holders to include a Reserved Font Name requirement, and the README warns that this option "is used with some of the fonts", adding that if you modify those fonts you must take care of that detail. The repository does not state a single licence for itself in what the README covers, which is itself worth noting: the font files carry their own licensing and authorship metadata, and the per-family licence file is the document that governs. This is a description of what the README says, not legal advice; a Reserved Font Name restriction on a modified font is the kind of thing to read carefully before redistribution.
Editorial conclusion
Adopt google/fonts if you need the actual .ttf binaries Google serves, want to self-host them through a tool such as Fontsource, or need to file a bug against a specific family. Do not adopt it as a source tree to edit: /axisregistry and /lang are git subtrees that must be changed upstream, and family files are generated from designer sources elsewhere. Before you ship anything, verify the licence file in the family directory you copied from, check whether the family carries a Reserved Font Name before you modify it, and confirm the exact path in the repository rather than trusting a CDN URL.
Frequently asked questions
How do I download all the fonts in google/fonts?
The README gives a ZIP snapshot of the whole collection at https://github.com/google/fonts/archive/main.zip and notes it is over 1GB. It also suggests syncing with git so that updates only fetch what changed.
Can I self-host fonts from google/fonts?
Yes. The README states that all fonts here are licensed with permission to redistribute, subject to the licence terms, and points to Fontsource for bundled NPM packages and fnt for installing single fonts on Linux, macOS, FreeBSD or HaikuOS.
Where do I report a problem with a font in google/fonts?
The README asks you to create a new issue in the project's issue tracker at https://github.com/google/fonts/issues for problems with a font file or requests about a font project's future development.
Can I edit files in the axisregistry or lang directories of google/fonts?
No. The README says both are subtrees and that no changes should be made directly in this repository; they come from github.com/googlefonts/axisregistry and github.com/googlefonts/lang respectively.
What licence do the fonts in google/fonts use?
Most use the SIL Open Font License v1.1, some use Apache 2, and the Ubuntu fonts use the Ubuntu Font License v1.0. The README says to always read the licence for every font you use, since each family directory contains its own licence file.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/google-fonts)