Mona Sans: GitHub's Variable Typeface, Its Axes and What Adopting It Costs

The problem Mona Sans solves for product teams

Most typeface families ship as a pile of static files: one per weight, one per width, one per italic. Every extra cut is another request, another cache entry, and another chance that a designer picks a weight the build does not include. Mona Sans is a variable font, which the README describes as a format where "different variations of a typeface" live in one file, supported by all major browsers. That single-file premise is the whole pitch: instead of choosing between Regular and Bold, you interpolate anywhere between wght 200 and 900, and between wdth 75 and 125.

The intended audience is narrow and identifiable. The README says the typeface was designed with Degarism and inspired by industrial-era grotesques, and that it "works well across product, web, and print." That is a product-design audience: people building interfaces who need a heading weight, a body weight, a condensed label, and a mono for code, all visually related. GitHub also publishes Hubot Sans, described as Mona Sans's sidekick, so the family is meant to be paired rather than used alone. If you are setting a single paragraph of body text on a brochure, the axis machinery buys you very little.

How the design space is actually split

The README is explicit that the design space was too large for one file, so the font ships as several variable fonts. The full build is named MonaSansVF[wdth,wght,opsz,ital], and that is the one to reach for when you want everything. Four axes are exposed: wght from 200 to 900, wdth from 75 to 125, ital as a 0 or 1 switch, and opsz from 1 to 100.

The optical size axis is the part worth understanding before you wire anything up. According to the README, values from 1 to 20 are tuned for body text with improved readability, while 21 to 100 are tuned for display use with "refined details and tighter spacing." With font-optical-sizing: auto, the browser picks the value from the rendered font size; you can also set it by hand. The repository also states that the design space now spans 168 instances after monospace, display and display italic styles were added, and that style entries marked with a hyphen in the mapping tables are elidable, meaning they are the default and carry no name. That last detail matters in practice: a named instance like "Expanded" is a point in the space, not a separate file you can fetch.

Installing Mona Sans and getting a first page rendering

The repository does not publish an npm package or a system installer. The README's download route is the releases page, and the microsite link points at the project's own GitHub Pages-style home. So installation means downloading the release archive, taking the woff2 build you need, and referencing it from CSS. The @font-face block below is the one the README gives, with the two-format source list that tells the browser the file supports variations.

@font-face {
  font-family: 'Mona Sans VF';
  src:
    url('MonaSansVF[wdth,wght,opsz,ital].woff2') format('woff2 supports variations'),
    url('MonaSansVF[wdth,wght,opsz,ital].woff2') format('woff2-variations');
  font-weight: 200 900;
  font-stretch: 75% 125%;
  font-optical-sizing: auto;
}

html {
  font-family: 'Mona Sans VF';
}

After that, the family name 'Mona Sans VF' resolves and the browser interpolates instead of snapping to a static cut. To prove the axes are live, set an explicit variation on a heading and compare it with the same text at default settings. The README's own example uses wght 700, wdth 125 and opsz 72 for a display heading, and wght 400, wdth 100 and opsz 12 for body text:

.heading {
  font-variation-settings: "wght" 700, "wdth" 125, "opsz" 72;
}

.body-text {
  font-variation-settings: "wght" 400, "wdth" 100, "opsz" 12;
}

If the heading looks wider and tighter than the body, the width and optical size axes are working. Finally, the README recommends preloading to reduce CLS, and gives this tag for the document head:

<link rel="preload" href="MonaSansVF[wdth,wght,opsz,ital].woff2" as="font" type="font/woff2" crossorigin>

One practical note the README does not address: the filename contains square brackets and commas. Those characters are legal in a URL path once percent-encoded, but they will break naive asset pipelines and some deploy scripts, so decide early whether to rename the file or encode the path.

Stylistic sets, ligatures and the mono family

Mona Sans carries ten stylistic sets, listed in the README as ss01 through ss10. They cover square diacritical marks, a wide uppercase I, two different lowercase l treatments, double-storey a and g, a square G, a tabular zero with a straight bar, a Q with a diagonal arm, and a J with a bowl. On the web these are toggled with font-feature-settings, and the README's example turns on ss01, ss03 and ss05 at once. Seven ligatures ship as well: ff, ffi, fy, fi, fl, ti and tt.

The mono styles are the second half of the story. The README presents Mona Sans Mono with its own weight and width tables, wght 200 to 900 and wdth 75 to 125, and no italic axis listed. That asymmetry is the design trade-off: the proportional family has four axes, the mono has two. If your interface pairs code blocks with prose, the mono will match in weight and width but will not follow the optical size or italic settings you apply to the rest of the page. The README does not state whether the mono is a separate variable file or a named instance inside the main build, and it does not document how the two are meant to be requested together.

Where Mona Sans is the wrong choice

The clearest limitation is the one the README states without softening: the design space was large enough that the font had to be split into several variable fonts. You cannot hand a single file to a print vendor and expect every axis. If your workflow needs static, per-weight cuts, you are working against the format's grain.

The second limitation is documentation depth. The README covers web usage well and says nothing about how the sources/ directory is organized, what build.log contains, or how to rebuild the font from source. The only build dependency listed in requirements.txt is gftools, which tells you the font is built with Google Fonts tooling, but the repository does not describe the build command, the source format, or the output targets. A team that needs to modify a glyph, add a language, or reproduce the release artifact bit for bit will find no instructions here. The README also does not document rollback: if a new release regresses rendering, there is no stated procedure for pinning or reverting beyond downloading an older release.

The third case is subtler. Optical size is automatic when font-optical-sizing is auto, which is convenient until it is not. A heading rendered at 72px and the same heading rendered at 20px will not be identical shapes, and if a design review compares a static mockup against the live page, the difference will look like a bug. Teams that need absolute predictability across breakpoints should set opsz explicitly rather than let the browser decide.

Mona Sans against Inter and other UI sans families

The obvious comparison, and one people search for, is Inter. The difference in approach is the axis set. Inter is widely used as a UI text face and has been distributed in variable form, but Mona Sans's distinguishing feature is the width axis: wdth 75 to 125 gives you Condensed through Expanded from the same file, and the README's mapping table names each step (Condensed, SemiCondensed, SemiExpanded, Expanded). A team that needs to fit long labels into narrow table columns without switching families gets that from one download. Inter's strength is the opposite: it is a workhorse text face with an enormous community of derivative work.

Hubot Sans is the in-family alternative rather than a competitor. The README describes it as Mona Sans's sidekick and says the two are made to work well together, so the real choice is whether you want one typeface or a pair. If you are evaluating alternatives, the honest framing is that Mona Sans's width axis and its mono companion are the two features that are hard to replicate by swapping in another grotesque. Its optical size axis is a refinement, not a reason on its own.

Licence and the cost of keeping up

Mona Sans is licensed under the SIL Open Font License v1.1, and the repository carries both LICENSE and OFL.txt at the top level. The OFL permits use, modification and redistribution of the font, including bundling it with software, provided the reserved font name rules and the licence notice requirements are respected. That is a summary of what the licence is, not advice: if you plan to modify the glyphs and redistribute under the Mona Sans name, read the OFL text in the repository and get your own legal read, because the reserved-name clause is the part that catches people.

The upgrade cost is visible in the release history. Three releases landed within four days in May 2026 (v2.0.25 on 2026-05-15, v2.0.26 on 2026-05-18, v2.0.27 on 2026-05-19), and the last push to the repository was on 2026-09-10. That cadence is high enough that pinning a specific release is worth doing rather than tracking latest. Because the font is a binary asset, an upgrade is a visual change: you should render a fixed specimen page against the old and new files before swapping, since the README documents no changelog detail per release beyond the version number.

Editorial conclusion

Adopt Mona Sans if you are comfortable serving one variable woff2 and controlling weight, width, optical size and italic through font-variation-settings, and if a mono companion sharing the same axes matters to your UI. Do not adopt it if you need static per-weight files, a documented rollback path, or a font you can audit character by character in this repository, because the README does not document rollback and the sources/ and fonts/ directories are not described in the README at all. Before you commit, verify three things on your own machine: that the browser you must support accepts the format('woff2 supports variations') declaration, how your text renders at opsz values near 12 and near 72, and whether the stylistic sets you plan to switch on (ss01 through ss10) exist in the specific file you downloaded rather than only in the full MonaSansVF[wdth,wght,opsz,ital] build.

Frequently asked questions

Official sources

1. github/mona-sans on GitHub
2. License: OFL-1.1
3. Project website
4. README
5. Releases