Why Libre Baskerville with Source Code Pro works for open-source READMEs

It delivers immediate readability across code blocks and prose without visual competition. You see the hierarchy: headings in Libre Baskerville, inline commands and file paths in Source Code Pro, all at comfortable sizes and weights.

What this pairing actually does and when it fits

Libre Baskerville is a serif font designed for screens and print, with generous x-height and open counters. Source Code Pro is a monospace font built for legibility in terminals and code editors not just syntax highlighting, but structural clarity in filenames, flags, and CLI examples.

This pairing fits best in READMEs where users scan quickly: installation steps, configuration snippets, or error messages. It avoids the fatigue of all-monospace docs (like those using only JetBrains Mono) while keeping technical content distinct from narrative text.

How to adjust based on your project’s needs

If your README includes long explanatory sections like architecture overviews or design rationale increase the line height for Libre Baskerville (1.6–1.7) and tighten spacing around code blocks. For CLI-heavy tools (e.g., CLI scaffolders or DevOps utilities), set Source Code Pro at 14px with letter-spacing: 0.025em to improve character separation without distortion.

For accessibility, avoid light or thin weights. Use Libre Baskerville Regular (not Light) and Source Code Pro Regular or Semibold both ship with full Unicode support and consistent baseline alignment.

Common mistakes and how to fix them

Using Source Code Pro for paragraph text makes documentation feel cold and fragmented. Fix: Reserve it strictly for code, paths, and command-line output.

Setting both fonts at identical size (e.g., 16px for both) flattens contrast. Fix: Use 18–20px for Libre Baskerville body, 14–15px for Source Code Pro the size difference reinforces semantic roles.

Ignoring font loading order causes FOIT or layout shifts. Fix: Preload both fonts in your static site generator or GitHub Pages config. Test rendering in Safari, which handles variable font fallbacks differently than Chrome or Firefox.

Your next step: a 3-item README typography checklist

  • Verify that font-family declarations separate serif and monospace cleanly e.g., font-family: 'Libre Baskerville', serif; for paragraphs, and font-family: 'Source Code Pro', monospace; for <code> and <pre>.
  • Check contrast ratios: Libre Baskerville text on white should meet WCAG AA (4.5:1). Avoid gray-on-gray code comments use IBM Plex Mono alternatives only if Source Code Pro renders poorly in your build toolchain.
  • Preview your README in both GitHub’s rendered view and a local Markdown previewer they apply different default styles, and spacing inconsistencies often appear only in one.
Download Now