Blog · Typography

Reading code with dyslexia - Fira Code, JetBrains Mono, and OpenDyslexic Mono

10 min read · May 8, 2026

Most advice about dyslexia-friendly fonts assumes you are reading prose. Code is different. The lines are shorter, the syntax is unforgiving, and a single misread character can mean an hour of debugging. The fonts that work for a long article are not always the same fonts that work for a 200-line file - and the things that go wrong when you have dyslexia are specific enough to deserve their own guide. Here is what actually helps when you write or review code with dyslexia, the typefaces worth trying, and the IDE settings to change today.

The short answer

Why coding is harder than prose for dyslexic readers

Reading prose is forgiving. If you misread a word for a fraction of a second your brain almost always recovers from context - the surrounding sentence narrows the possibilities. Code does not give you that. userld and userId look identical at a glance and mean entirely different things. O and 0 can sit one line apart in a hex value or a serial number with nothing to disambiguate them. The contextual rescue that helps a dyslexic reader skim a paragraph is mostly absent.

On top of that, code is dense in punctuation, which is where dyslexic readers often spend the most attention. Semicolons, commas, colons, periods, and brackets carry meaning the way a verb tense does in prose. Misread a single one and the parser does not forgive you.

So the criteria for a good coding font are slightly different from the criteria for a good reading font. They are also different from the criteria for a good UI font. The three things that matter most are character disambiguation, vertical rhythm, and weight calibration.

The five characters that cause the most trouble

Across the dyslexic developers I have talked to and the open issues on font repositories, the same handful of glyph confusions come up over and over.

0 vs O vs o

The single biggest gain you can make. A coding font worth using draws zero with either a slash or a dot in the middle. Without that disambiguation, hex codes, IDs, and any data with mixed digits and letters become a guessing game. Menlo (the Mac default) does this passably. Cascadia Code does it well. Fira Code and JetBrains Mono both ship with a slashed zero and a clearly different uppercase O.

1 vs l vs I (and sometimes |)

The second-biggest gain. The lowercase L is the worst offender - in a default font it is a vertical line indistinguishable from a 1 or an uppercase I. Look for a font where the lowercase l has a small foot, tail, or curve. Fira Code uses a tail. JetBrains Mono uses a curve. Both are far ahead of Menlo or Consolas at this character, where the only difference is the relative position of the digit.

; vs : (and , vs .)

At small sizes on a low-DPI screen, the dot of a semicolon and the upper dot of a colon almost merge. This is where vertical spacing matters: a font drawn with more height for punctuation, and a line-height that gives each row breathing room, separates them visibly. JetBrains Mono is particularly careful here.

b vs d vs p vs q

The classic dyslexia confusion - except that in code these letters appear in identifier names where context is thinner than in prose. Most monospace fonts do nothing about this. OpenDyslexic Mono is the one option that bottom-weights these glyphs to make their orientation impossible to confuse. If b/d/p/q is your specific weak point, this is the only typeface in this guide that addresses it directly.

{ } [ ] ( )

Bracket recognition is less about dyslexia and more about visual fatigue. The fix is not the bracket shape itself - all monospace fonts get this right - but bracket pair colourisation, which most modern editors now offer as a built-in feature. Turn it on. The colour cue is faster than the shape cue.

The contenders

JetBrains Mono

JetBrains shipped this font in 2020 specifically for sustained code reading. It is taller than most monospaces (slightly larger x-height), has a slashed zero, a curved lowercase l, and unambiguous bracket pairs. The weight axis is generous (100 through 800), which lets you sit at 450 or 500 without going to true bold. For dyslexic readers, JetBrains Mono is usually the best starting point - it gets the basics right and does not require an adjustment period.

Fira Code

Fira Code is the older sibling, a fork of Mozilla's Fira Mono with programming ligatures added. The character disambiguation is slightly less aggressive than JetBrains Mono - the lowercase l has a tail rather than a curve, the slashed zero is thinner - but the typeface is excellent and very widely supported. It is the font most readers will already have somewhere on their system. The big footnote is the ligatures, discussed below.

Cascadia Code (and Cascadia Mono)

Microsoft's coding font. Slightly more humanist than JetBrains Mono, with a friendly italic. The dotted zero is a different choice from the slashed zero - some dyslexic readers find dots easier to spot than slashes, others the reverse. Worth trying if JetBrains Mono is your second-best. Cascadia Mono is the same font without ligatures and is the version most worth installing.

OpenDyslexic Mono

The only monospace typeface designed specifically for dyslexia. Like the proportional OpenDyslexic face, every letter is bottom-weighted so it cannot be flipped or mirrored without obviously changing shape. In a monospace context that disambiguation extends to b/d/p/q across identifiers, which no other font in this guide does. The trade-off is honest: the typeface is unconventional, the rhythm is heavier than a typical coding font, and your eye needs about a week to fully settle into it. If b/d/p/q is the confusion that costs you the most, it is the right choice. If your weak point is digits and punctuation, JetBrains Mono will probably serve you better.

Atkinson Hyperlegible Mono

The Braille Institute's Atkinson Hyperlegible family expanded to a monospace variant in 2024. It was designed for low-vision readers, and the same character-disambiguation philosophy applies: every glyph is drawn to be impossible to confuse with another. It is the best choice if you have low vision in addition to dyslexia, or if your screen is small. It is newer and less widely shipped, so you will need to install it manually.

Comic Code

A monospace cousin of Comic Sans, paid commercial. Some dyslexic developers swear by it for the same reason readers swear by Comic Sans for prose - the slightly irregular shapes give every letter a distinct personality. It is the most divisive choice in this guide and worth trying only if the more standard options have not stuck.

The ligatures question

Programming ligatures merge multi-character sequences (!=, =>, <=, ::, ===) into a single combined glyph. Fira Code popularised them; JetBrains Mono and Cascadia Code both support them.

For dyslexic readers, ligatures are a mixed bag. The case for them: the merged glyph reads as a single concept, which can reduce cognitive load if you already understand the operator. The case against: the visual shape of the merged glyph hides the actual characters in the file, which can be confusing when you are typing or when you need to count characters. More importantly, several dyslexic readers report that ligatures make some operators harder to distinguish - for example, the merged >= and => glyphs in some fonts look more similar than the underlying character pairs do.

The honest recommendation: turn ligatures off by default and try them only after you have dialled the rest of your setup in. If your font choice and spacing are dialled, ligatures might be a small bonus. If they are not, ligatures are a layer of magic that hides confusion.

// In VS Code settings.json
"editor.fontLigatures": false,
"editor.fontFamily": "'JetBrains Mono', Menlo, Consolas, monospace",
"editor.fontWeight": "450",
"editor.fontSize": 15,
"editor.lineHeight": 1.6,

Size, weight, and line-height for code

The default in most editors is 12-13px at weight 400 with a tight line-height around 1.4. For dyslexic readers, every one of those numbers is too small.

Size: 14-16px is the sweet spot for code on a desktop monitor. Going to 17 or 18 helps for very long sessions, but at that size you start losing useful horizontal context (the right edge of long lines disappears off the screen). The tension is real and the answer is to combine slightly larger text with reasonable monitor width.

Weight: in code, the same pattern as prose font weight applies - regular (400) is too thin on most modern displays for sustained reading, and bold (700) closes the letter counters. Sit at 450 or 500 if your font supports it. JetBrains Mono and Fira Code both have full variable weight axes; Menlo and Consolas do not.

Line-height: the single most underrated setting. Default editor line-height of 1.2-1.4 is uncomfortable for most dyslexic readers. Bump it to 1.55-1.7. Yes, you will see fewer lines on screen at a time. But you will read every line you do see substantially faster, and the cost is much lower than it looks - the eye does not need that lost vertical real estate.

Editor settings worth changing today

Even with a perfect font, an editor's defaults will fight you. Five settings to change in VS Code, JetBrains IDEs, or whatever you use.

1. Bracket pair colourisation. In VS Code, set "editor.bracketPairColorization.enabled": true and "editor.guides.bracketPairs": true. The horizontal lines that connect matching brackets are particularly useful when nesting goes more than two deep.

2. Indent guides. Enable rainbow indent guides if your editor offers them. The vertical lines mark scope without you having to count whitespace - which is exactly the visual labour dyslexic readers want to avoid.

3. Soft warm theme. Pure white-on-pure-black hurts more than it needs to. Try a warm dark theme like One Dark, Solarized Dark, or Tokyo Night - the slightly off-black background reduces glare. If you prefer light themes, look for one with a cream or off-white background rather than pure white. The same logic from the background colours guide applies to code.

4. Disable italic comments. Many themes set comments in italic. For dyslexic readers, italic at small sizes is harder to parse than upright text. Override the italic style in your theme settings - comments are read often and should be the easiest thing on the screen, not the hardest.

5. Increase the cursor width. A 1px cursor can vanish. Set "editor.cursorWidth": 3 in VS Code and pick a theme where the cursor colour is bright. Losing the cursor in code is a small thing that adds up across a day.

Reading code in the browser

A surprising amount of code reading happens in the browser - GitHub diffs, Stack Overflow answers, MDN documentation, internal wikis. The fonts those sites pick are not always the ones you would pick yourself.

GitHub uses SFMono-Regular, Consolas, Liberation Mono by default, which means most users see Consolas (Windows) or Menlo (Mac). Both have weak character disambiguation. Stack Overflow uses Consolas. MDN uses Source Code Pro, which is better but not great. None of them ship with the line-height a dyslexic reader wants.

This is exactly where LexiFont earns its keep. The extension applies your chosen font to body text on every site you visit, and you can scope code-block selectors so that pre, code, and kbd elements use a chosen monospace - say JetBrains Mono - across GitHub, Stack Overflow, MDN, and your team's wiki. Pair that with a slightly larger size and a bumped line-height and reading code in a browser becomes as comfortable as reading code in your editor. LexiFont Pro ships with the dyslexia-specific monospaces (OpenDyslexic Mono, Atkinson Hyperlegible Mono) that most sites do not include in their defaults.

A starter setup, ready to copy

If you want a working starting point that you can tune later, here is the configuration most dyslexic developers I know land on after a couple of weeks of experimenting.

Testing what works for you

The first-glance test for a coding font is misleading the same way it is for prose - everything looks fine in the first few minutes. Use it for a real piece of work. Open a file you know has gnarly identifiers (something with hex constants, a few userId variants, some date formatting) and read it for an hour. Then open the same file in your previous setup and read for another hour. The differences emerge at the end of the second hour, not the start.

Two specific things to track: how often you have to copy a value out and paste it elsewhere to read it (a sign of character ambiguity in the font), and how often you re-read a line because you think you misread something (a sign of crowding or weight). If either number drops noticeably, the new setup is worth keeping.

The takeaway

Coding fonts have come a long way. The defaults you get on a fresh install of any major editor are probably ten years out of date and worth replacing. For dyslexic developers in particular, the gains from a thoughtful font, a generous line-height, and a slightly heavier weight stack on top of each other - and they show up most when the day gets long.

JetBrains Mono is where most readers should start. Add OpenDyslexic Mono if b/d/p/q is your specific weak point. Bump line-height to 1.6, weight to 450 or 500, and turn off ligatures and italic comments. You will not feel the difference in the first hour, but you will feel it in the third.

Get LexiFont Pro - dyslexia fonts in your editor and your browser for $14.99 one-time

Further reading

• Best fonts for dyslexia in 2026 - a research-first guide
• Font weight and dyslexia - does bold actually help?
• Line spacing and letter spacing for dyslexia
• OpenDyslexic vs Lexend - side by side
• Background colours for dyslexia - cream, blue, or grey?