Back to the blog
Open SourceFontsTools

Iosevka: the monospaced font you compile yourself

November 02, 2026·6 min read·Diego Horvatti

You open two files side by side, and the editor starts wrapping everything past 100 characters. Before you buy a bigger monitor, there's a free fix worth testing: Iosevka, an open source monospaced font that's narrow and so configurable you can compile your own version. It comes in sans and slab variants, and the official site even includes a configurator for generating a custom build.

Iosevka isn't new. The project has been around for about a decade, is maintained by Belleve Invis and uses the SIL Open Font License. It keeps resurfacing in dev discussions because it solves a problem most fonts ignore: everyone wants a different detail, and Iosevka lets you choose.

What makes the Iosevka font different?

The first difference is width. Each Iosevka character takes up 0.5 em, while JetBrains Mono and Fira Code take up 0.6 em. It sounds small, but the math changes a lot:

  • At 14px, each Iosevka character is 7px wide.
  • In JetBrains Mono, it's 8.4px.
  • On a 960px panel, that's 137 columns against 114.

That's 23 extra columns in the same space, without reducing the text size. In an editor split with a terminal alongside it, you'll notice.

The second difference is how it's made. Most fonts come out finished from a type editor. Iosevka is generated by code: the glyphs are described parametrically, and a build assembles the families. That's why it can offer so many combinations of weight, width, serif and letter shape.

The third is the catalog of ready-made styles. The stylistic sets imitate the feel of other well-known fonts. ss14 resembles JetBrains Mono, ss05 resembles Fira Mono and ss09 resembles Source Code Pro. You can change the font's personality without changing fonts.

A code font is a tool. If you spend eight hours a day looking at it, you can tune it the way you tune your linter.

Iosevka, Term or Fixed: which variant should you use?

This is the question that stalls most newcomers. The difference lies in how each variant handles width and ligatures:

  • Iosevka: the default version. It has ligatures, and some symbols, like arrows, take up more space.
  • Iosevka Term: symbols and arrows stay inside one cell. It's the safest choice for the terminal and, in my opinion, for the editor too.
  • Iosevka Fixed: no ligatures. It's for terminals and programs that break alignment when they hit a ligature.

There are also two quasi-proportional families, Aile (sans) and Etoile (slab). They don't work for code, but they do well in documentation, notes and interfaces. If your blog uses Iosevka in code blocks, Aile can sit alongside it in the body text without any odd contrast.

If you can't be bothered to decide, install Term. It avoids most surprises.

How to install and test it in VS Code

On macOS, Homebrew handles it:

brew install --cask font-iosevka

On Linux, check your distro's repository or download the package from the GitHub releases page. I prefer to download only the family I'll use. The all-in-one package is big, and you won't need every variation.

Then adjust the editor. Here's an example for VS Code with Term and the JetBrains Mono inspired style:

{
  "editor.fontFamily": "Iosevka Term",
  "editor.fontSize": 15,
  "editor.lineHeight": 1.5,
  "editor.fontLigatures": "'calt', 'ss14'"
}

Notice the fontSize of 15. Because Iosevka is narrow, it looks smaller than your previous font at the same size. Going up one point usually makes up for it, and you still end up with more columns than before. A more generous lineHeight also helps, because narrow letters with tight lines get tiring fast.

In the terminal, the logic is the same. If yours uses a config file, like Kitty, just point it at the family:

font_family Iosevka Term
font_size 12.0

Is compiling your own Iosevka worth it?

In most cases, no. But this is where the font gets fun.

You can describe your version in a private-build-plans.toml file. It defines spacing, serif, base style and details of specific glyphs. For example:

[buildPlans.IosevkaDiego]
family = "Iosevka Diego"
spacing = "term"
serifs = "sans"
noCvSs = true
exportGlyphNames = false

[buildPlans.IosevkaDiego.variants]
inherits = "ss14"

[buildPlans.IosevkaDiego.variants.design]
zero = "dotted"

[buildPlans.IosevkaDiego.weights.Regular]
shape = 400
menuName = "Regular"
css = 400

[buildPlans.IosevkaDiego.weights.Bold]
shape = 700
menuName = "Bold"
css = 700

Then, with Node and ttfautohint installed, clone the repository and run the build:

npm install
npm run build -- ttf::IosevkaDiego

Option names change over time. Instead of trusting my example, generate the TOML in the official configurator and paste it into the project. It's faster, and you see the result before compiling.

A warning: the build uses a lot of CPU. If you ask for many weights and widths, your laptop turns into a space heater for a good while. Limit the plan to the weights you actually use, as in the example above. If you'd rather avoid all that, you can run the build on GitHub Actions and download the finished artifact.

It's worth it when you have a specific pet peeve: you dislike the 0, you want a different l, or you work with a small set of weights and want smaller files. If the default font already pleases you, compiling is just a hobby. A harmless hobby, but still a hobby. Nobody ever shipped a feature faster because the asterisk sat three pixels higher.

Can you use Iosevka on the web?

You can, but carefully. Its character coverage is huge, and loading the whole file on a website is a waste. If you only show code in Portuguese and English, make a subset with pyftsubset, from fontTools:

pyftsubset Iosevka-Regular.ttf \
  --unicodes="U+0020-007E,U+00A0-00FF" \
  --layout-features='*' \
  --flavor=woff2

This command keeps the basic Latin characters and the accents, and preserves the OpenType features, including ligatures. For --flavor=woff2 to work, the Python brotli package must be installed.

In Next.js, the next step is next/font/local, which hosts the font along with the site:

import localFont from 'next/font/local'

export const iosevka = localFont({
  src: './Iosevka-Regular.subset.woff2',
  variable: '--font-mono',
  display: 'swap',
})

On a product site, I'd think twice before using such a narrow font for running text. In code blocks and dense tables, it works well. In paragraphs, Aile or a regular sans is easier on the eyes.

What changes in your day to day

Let's be honest: changing fonts won't make you a better programmer. The gain is small, physical and daily. You see more columns, scroll sideways less and can keep two files open on a smaller screen.

There's also a real cost. A narrow font takes a few days to get used to, and not everyone adapts. If you struggle to read dense text, or you use a small font size, JetBrains Mono may remain the better choice. It has more breathing room, and breathing room is productivity too.

What I admire about Iosevka is the project itself. A font generated by code, with an open license and a build system any dev can understand, treats typography as software. You open a config file, change one line and compile.

My recommendation is simple: install Iosevka Term, use it for a week one point above your current size, then decide. If you don't like it, uninstalling takes one command. If you do, watch out: before long you'll be comparing variants of the number zero at two in the morning. If you enjoy this kind of obsession with detail, take a look at the projects I've been building around here.

LinkedIn summary

I changed my editor font and gained 23 columns without buying a monitor or shrinking the text.

Iosevka is open source and narrower: 137 columns against 114 for JetBrains Mono, on the same 960px panel.

What really got me was something else: it's generated by code. You edit a config file, change one line and compile your own font.

It won't make anyone a better programmer. The gain is small, physical and daily.

If you want to try it, install Iosevka Term and use it for a week, one point above your current font size.

I wrote the full walkthrough on the blog. Just be careful not to end up comparing variants of the number zero at two in the morning.

#Iosevka #OpenSource #SoftwareDevelopment #VSCode #Productivity