Methodology · data as of 15 Oct 2026
How does Fontwell check font licences?
We read the licence folder each family sits in on the official google/fonts repository, join it to Google Fonts’ public family metadata, and apply a fixed table of plain-English rules written from the licence texts. Nothing is scraped from third-party sites and nothing is estimated.
Data sources
| Source | What we use | As of |
|---|---|---|
| Google Fonts family metadata | Family names, categories, subsets, styles, variable axes, designers, dates added and modified, Google’s popularity and trending order, default metrics | 2026-10-15 14:46 UTC |
| google/fonts repository | The licence folder of each family (ofl/, apache/, ufl/), read from a tree-only clone at commit 9430147 | 2026-10-15 |
Family METADATA.pb files | Licence field, copyright line and upstream repository for the 200 families with their own page | same commit |
A refresh script fetches these sources with a descriptive user agent. If any fetch fails or looks incomplete (for example fewer than 1,000 families), the last good snapshot is kept and every page keeps showing that snapshot’s real date. The snapshot is rebuilt into the static site; there is no live database.
Matching families to licences
Folder names in google/fonts are the family name in lower case without spaces or punctuation (for example ofl/notosanskr). We normalise each metadata family name the same way and look it up. In the current snapshot 1,944 of 1,950 families match; 6 do not, and are labelled “licence unmatched” everywhere instead of being assigned a guess. The licence checker answers “we will not guess” for them.
Licence verdicts
Each of the eight uses in the licence checker has one verdict per licence: yes, with conditions or no, with a plain-English answer and the clause it rests on. The rules were written from the official texts of the SIL Open Font License 1.1, the Apache License 2.0 and the Ubuntu Font Licence 1.0, and are covered by automated tests. They describe the licence, not your situation: they are not legal advice, and a font’s own licence file always wins.
How pairings are scored
Pairing suggestions use only Google’s metadata. For a heading family H and a candidate body family B:
- B must be serif, sans serif or monospace, and offer a text weight range (400 and 700 among at least three static weights, or a
wghtaxis spanning 400 to 700). Otherwise it is excluded. - H and B must share the Latin subset or the same primary script. Otherwise excluded.
- Score +3 if their categories differ, +1 if H is display or handwriting, −2 if B is monospace.
- Score +2 × the share of subsets they have in common.
- Score −0.4 × the difference in Google’s width metric and −3 × the difference in default line-height.
- Score +1.5 ÷ log10(10 + B’s popularity rank), a small preference for well-tested families.
The three highest-scoring bodies from the 200 curated families are shown. The score is a shortlist generator, not a judgement of beauty; always proof the pair in the pairing tester.
Which families get their own page
The 200 highest-ranked families in Google’s popularity order that have a matched licence. We keep this number deliberately limited so each page carries a full licence matrix, coverage comparison, pairings and source links rather than thin templated text. Every other family remains searchable on the desk.
Specimens
Specimens are drawn by your browser from the Google Fonts CSS API using the text= parameter, so only the characters shown are downloaded. Each specimen has a fixed height, so fonts arriving late do not shift the page. You can switch specimens off; see the privacy policy.
Corrections
If a verdict, date or figure is wrong, email contact@fontwell.online. We correct errors in the next build and note material changes on the affected guide.