Best Fonts for Developer Docs, API References and CLI-Style UI

Documentation sites have a different problem from dashboards. A dense dashboard is short labels and numbers. A docs page mixes four things: long explanatory prose, code blocks, reference tables of parameters and types, and pasted terminal output. A font that is perfect for one of them is often wrong for another.

This post is about the whole docs page. For choosing an editor font, see Best Free Monospace Fonts for 2026. For pairing scores, see Pairing Monospace Fonts with Sans-Serifs.

What the docs frameworks ship

Start with what you get before you choose anything. These are the defaults in each framework’s own stylesheet:

Framework	Body text	Code
Docusaurus (Infima)	System stack (system-ui, -apple-system, Segoe UI…)	System stack (SFMono-Regular, Menlo, Consolas…)
Starlight (Astro)	System stack	System stack (ui-monospace, SFMono-Regular…)
VitePress	Inter, bundled as subsets	System stack (ui-monospace, Menlo, Consolas…)
mdBook	Open Sans	Source Code Pro, at 0.875em
rustdoc	Source Serif 4	Source Code Pro

Two lessons. First, Docusaurus and Starlight don’t choose a font for you, and only mdBook and rustdoc load a web font for code. With a system stack, code renders in whichever monospace each platform has (the stacks list SF Mono, Menlo and Consolas, among others), so the same code block looks different from one reader to the next. Second, the projects that did choose (mdBook, rustdoc) chose Source Code Pro.

rustdoc is also a reminder that docs body text doesn’t have to be sans-serif. It sets prose in a serif by default, and its “Use sans serif fonts” setting switches to Fira Sans with Fira Mono.

Body text: choose for long reading

Docs prose is read in paragraphs, not glanced at in labels. You want a tall x-height, open shapes and a real italic for emphasis. These four are free (OFL) and include italics. Three of them have a monospace sibling:

• Inter: the tallest x-height here and an optical-size axis (opsz 14–32) that the browser applies automatically. Cyrillic and Greek included.
• IBM Plex Sans: more character than Inter, a width axis (wdth 75–100) for tight sidebars, and IBM Plex Mono as its sibling.
• Source Sans 3: Adobe’s. The most conservative choice, and its sibling Source Code Pro is the code font mdBook and rustdoc already use.
• Atkinson Hyperlegible Next: a refined version of the original Atkinson Hyperlegible, developed with the Braille Institute for readers with low vision and added to Google Fonts in January 2025. It has a monospace sibling, Atkinson Hyperlegible Mono (November 2024). Both are variable (wght 200–800).

Choosing between Inter and the newer UI sans-serifs? Geist vs Inter vs Satoshi compares them on x-height, numerals and licence.

Superfamilies solve inline code

Inline code inside a sentence is where most docs typography goes wrong. If the mono’s lowercase is taller than the body text, every code span looks shouty. If it’s shorter, it looks like a footnote. The usual fix is “set code at 0.9em”, but the right number depends on the two fonts. We measured the height of the x glyph in each Regular instance:

Body	x-height	Code	x-height	Code size for matching x-height
Geist	0.530	Geist Mono	0.530	1.00em
IBM Plex Sans	0.516	IBM Plex Mono	0.516	1.00em
Source Sans 3	0.486	Source Code Pro	0.486	1.00em
Atkinson Hyperlegible Next	0.496	Atkinson Hyperlegible Mono	0.496	1.00em
Inter	0.546	JetBrains Mono	0.550	0.99em
Open Sans	0.535	Source Code Pro	0.486	1.10em

The superfamilies match exactly, which is the strongest argument for them. Inter has no monospace sibling, but JetBrains Mono is within 1%. mdBook is the instructive case. Open Sans has a taller lowercase than Source Code Pro, and mdBook also sets code at 0.875em, so the lowercase in its inline code is about 20% shorter than the text around it.

You can pin the match in CSS rather than tuning font-size per element. font-size-adjust has worked in all major browsers since 2024:

:root {
  --font-body: "IBM Plex Sans", system-ui, sans-serif;
  --font-code: "IBM Plex Mono", ui-monospace, monospace;
}
body { font-family: var(--font-body); }
code, kbd, samp, pre {
  font-family: var(--font-code);
  font-size-adjust: 0.516; /* body font's x-height */
}

One note on Plex: IBM released a variable IBM Plex Mono (wght 100–700) in its GitHub repo in 2026, but Google Fonts still serves the static weights. Self-host it if you want one file.

Code blocks: width is the constraint

In a code block the question isn’t x-height, it’s how many columns fit. Most monospaced fonts are 0.6em per character: JetBrains Mono, Geist Mono, IBM Plex Mono, Source Code Pro, Fira Code and Commit Mono all are. At 14px that is 8.4px a character, so an 80-column line needs 672px plus padding.

Two are noticeably wider. Martian Mono is 0.75em per character at its default width, so the same 80 columns need 840px. Its wdth axis (75–112.5) brings it down to 0.6em at the narrow end. Intel One Mono is 0.614em, close enough not to matter.

Size code blocks in the code font’s own units and you don’t have to do the arithmetic:

pre {
  font-size: 0.875rem;
  max-width: calc(80ch + 2rem); /* 1ch = one character cell in a monospace font */
  overflow-x: auto;
}

API reference tables

A reference page is mostly tables: parameter, type, default, description. Three things make them easier to scan:

• Names and types in the mono, descriptions in the body font. The contrast is what lets the eye run down the first column.
• Aligned numbers. Limits, sizes and timeouts in a column should line up. IBM Plex Sans and Source Sans 3 have tabular figures by default. Inter needs font-variant-numeric: tabular-nums. Best Fonts for Legible Numerals in UI Design covers the details.
• Unambiguous IDs. Keys, hashes and request IDs get copied by hand. Every free mono in this post separates 0 from O with a dot or a slash by default. In the body font, Inter’s zero feature (font-variant-numeric: slashed-zero) helps where IDs appear in prose.

CLI and terminal-style UI

Docs often embed terminal output, and some products render whole TUIs in the browser: tree views, progress bars, boxed tables. Those are drawn with the Unicode box-drawing block (128 characters, U+2500–257F) and block elements (32 characters, U+2580–259F). If the font lacks them, the browser substitutes another font for those glyphs and the borders stop lining up with the text.

We checked the Google Fonts builds (and Commit Mono’s own release) on 2026-10-18:

Font	Box drawing	Block elements	Braille patterns
JetBrains Mono	128 / 128	32 / 32	—
Geist Mono	128 / 128	32 / 32	—
IBM Plex Mono	128 / 128	32 / 32	—
Source Code Pro	128 / 128	32 / 32	—
Fira Code	128 / 128	32 / 32	—
Intel One Mono	128 / 128	32 / 32	—
Commit Mono	127 / 128	32 / 32	256 / 256
Martian Mono	0	0	—
Atkinson Hyperlegible Mono	0	0	—

Braille patterns are what the common “dots” CLI spinner (⠋⠙⠹⠸…) is drawn with, and only Commit Mono has them here. Martian Mono and Atkinson Hyperlegible Mono are fine for code samples but the wrong choice for anything drawn with box characters.

Commit Mono is worth a look for terminal-style UI generally. It is OFL-licensed and its “smart kerning” shifts letters within their fixed cells to even out the spacing between wide and narrow neighbours, without breaking the grid. Its site lets you bake alternates and spacing into a custom download. Commit Mono vs JetBrains Mono shows the two side by side.

Free vs paid

Two paid monospaced families come up whenever developers talk about fonts, and both have licence terms that matter for docs:

• Berkeley Mono (U.S. Graphics Company) comes in 5 widths, 12 weights and 2 slants, with variable fonts covering wdth, wght and slnt. The Developer licence is personal use only. Commercial licences are tiered by company size, are limited to UI elements, and the foundry says they are “not compatible with open-source apps”. If your docs live in a public repo, that rules it out.
• MonoLisa has a personal Developer licence (MonoLisa Code) and a commercial Creator licence that adds the proportional MonoLisa Text. MonoLisa vs JetBrains Mono compares it with the free default.

For an open-source docs site, the honest recommendation is a free font you can commit to the repo: JetBrains Mono or Commit Mono for character, Source Code Pro or IBM Plex Mono for a superfamily match. All of them are under the OFL.

A starting stack

If you want one answer for a new docs site:

:root {
  --font-body: "Inter", system-ui, sans-serif;
  --font-code: "JetBrains Mono", ui-monospace, monospace;
}
body {
  font-family: var(--font-body);
  font-size: 1rem;
  line-height: 1.65;
}
code, kbd, samp, pre {
  font-family: var(--font-code);
  font-size-adjust: 0.546; /* match Inter's x-height */
  font-variant-ligatures: none;
}
table { font-variant-numeric: tabular-nums; }

Ligatures are off because readers copy code from docs, and != should look like the two characters they’ll paste. Swap the pair for IBM Plex Sans with IBM Plex Mono, or Source Sans 3 with Source Code Pro, if you want a superfamily.

FAQ

What font does Docusaurus use? None by default. Infima, its CSS framework, uses the system UI font stack for text and a system monospace stack (SF Mono, Menlo, Consolas…) for code. Starlight does the same. VitePress is the exception and bundles Inter.

Should docs code blocks use programming ligatures? Usually not. Readers copy code from docs, and ligatures make != or => look like a character they can’t type. Leave ligatures for the editor.

What size should inline code be? Whatever makes its x-height match the body text. For a matched superfamily that is 1em. For Open Sans with Source Code Pro it is about 1.1em, larger rather than the usual 0.9em. The table above has the ratios.

Is a serif ever right for docs? rustdoc uses Source Serif 4 for body text by default, so it is a real option for long-form reference material. Keep code, navigation and tables in a sans or mono.

Which mono is best for terminal-style UI in the browser? One with the full box-drawing and block-element sets: JetBrains Mono, Geist Mono, IBM Plex Mono, Source Code Pro or Fira Code. Commit Mono adds Braille patterns for spinners.