If you would like to include a new font family in the Google Fonts collection, we’ll be happy to include it if it meets the following criteria and passes a review process:
The typeface design must be original, or a legitimate revival of a design in the public domain, and of good quality.
The Google Design team curates the overall Google Fonts collection and decides if fonts are of good quality. Google Fonts may reject families if they fail to meet their criteria. You can get general reviews of your project from the wider international type community during development by posting review requests in the googlefonts-discuss group, and the typedrawers review forum.
The project must be wholly licensed under the SIL Open Font License v1.1.
There must also be no proprietary/restricted-license versions of the project available elsewhere (such as additional weights/styles). Agreeing to publishing a font on Google Fonts means that you agree to licensing under the OFL all the existing styles of a same family, and the ones to come. For example, Mono, Proportional, Display, Text, Serif, Sans-Serif… are considered styles (or subfamilies) of the same font family, and should therefore be open source as well.
Refer to the dedicated chapter to know more about the license file requirements.
The Open Font License should not have any Reserved Font Names (why).
The copyright holders must all have filled in the Google Contributor’s License Agreement forms.
The font family name should not include any copyright holder’s full names.
First names are accepted, though. No registered trademarks, no initials or abbreviations, no references to languages or writing systems, and no cultural reference that may be offensive in any way. Use only ASCII alphanumeric characters in the family name and begin with an alphabet character, no dashes nor diacritics. Aim for a simple and unique name, ideally short and easy to remember. Long names can be harder for people to remember and type correctly and problematic for software with name length limitations.
CamelCase names are not allowed except in some cases discussed and approved by a Google Fonts team member.
If you are making a libre version of your prior proprietary font or designing something in an established genre, add “Libre” or a local equivalent to that well-known name e.g. Vesper Libre or Libre Baskerville.
A limited but easy way to test for uniqueness is namecheck.fontdata.com along with a general web search for name + font.
Refer to the dedicated chapter to know more about Authors and Contributors.
The project must be developed on GitHub or similar platform.
A VCS open to public participation and actively maintained. Please read our Github guide.
The source files are available in your preferred font editor format.
The file formats most used are UFO, .glyphs, .glyphspackage, fontforge or fontlab 7.
.glyphspackage is preferred over .glyphs due to it being easier to work with in version control (Git). Fontlab V files must be converted to another format because the software runs only on older OS versions. If you are using any font format other than .glyphs, .glyphspackage, and .ufo, include a build script that converts the sources to UFO, and include the UFO sources in the Git repository. Use Fontlab to UFO or FontForge to UFO for example.
The build should follow the Scalable Font Production principle.
Fonts are built using Fontmake, which can generate binaries from UFO. Fontmake can also convert .glyphs files to UFO, but if you are using any other font format, your build process should contain a step that converts the sources to UFO. Read the chapter about building fonts to know more about the build process.
All binary font files must be available in TTF format.
All font files should support, at least, the “GF Latin Core” glyph set.
All font files should follow the Overall font files requirements.
All font files should pass the FontBakery checks for the googlefonts profile. Please read the QA section of the Google Fonts guide for more information on quality assurance requirements.
All font source files should follow the outline quality guide.
Under special circumstances, you can request an exception to these requirements.
Remember, following the information given in the production requirements, the fonts used on websites via HTTP request to Google Fonts are served from the actual fonts contained in the API. In fact, Google Fonts contains more than a thousand fonts, and serves them to billions of websites. A very important detail to remember is that Google Fonts does not serve more than one version of the same font. This means that once a font is upgraded and in production, the upgrade is served everywhere.
To make sure users are correctly served the upgraded font:
The family name and style names should be the same.
The version number should be incremented from the previous version following the specified versioning criteria.
The visual thickness and width of the glyphs must be the same.
Visual weight and width of a font influence the overall “grey” of a paragraph and change the line length. Users get very angry when the weight/width of a style has changed.
The line length must be kind of the same.
The font spacing can be improved whenever needed, but upgrades must not create an obvious change in line length or significant reflow of text for end users.
The interline space must be the same.
The vertical metrics must be the same so that the line spacing has the same visual appearance to end-users.
The rendering should be of the same quality.
This means that the hinting should match as closely as possible. Manual hinting programs from previous versions should be re-applied to the new binaries. More information about that matter is given in the Static font requirements, and in the Variable font requirements.
Contributions from forks are not accepted.
We need to make sure that the original author of the font has agreed with the upgrade, therefore:
All of these requirements are to be navigated with the statistics of use in mind; exceptions to compatibility requirements can be made for fonts that are not heavily served.
If an upgrade is too much of a change, we can consider onboarding it as a new font with a different family name. We then decide if the old versions remain visible on the catalogue, and/or whether to make the old version unavailable for new users. This allows websites to be served with the old version that they already use, while new requests would get the upgraded versions.
Since all the fonts available are licensed with permission to redistribute subject to the license terms, if you want to have more control over the version of the font you use you can self-host the font using a variety of third-party projects.