Blog · Developer tools
VS Code settings for developers with dyslexia
Most advice about dyslexia and reading assumes the problem is a webpage or a document. But if you write code for a living, your actual reading environment is a monospaced editor — dense, visually uniform, and open for eight or more hours a day. The stakes of getting it wrong are higher: misread a variable name or a closing bracket and the bug you introduce can take an hour to find. Here is a practical guide to making VS Code easier for developers with dyslexia, without sacrificing the features that make it a good editor.
Why VS Code's defaults are a rough starting point
VS Code ships with Consolas on Windows and Menlo on macOS — serviceable monospaced fonts with decades of use. Neither was designed with dyslexic readers in mind. Both have tight letter spacing, relatively thin strokes, and several ambiguous character pairs that cause misreadings even for people without dyslexia: lowercase L (l), the numeral one (1), and the capital letter I (I) are nearly identical in Consolas at most sizes. The same goes for the numeral zero (0) and capital O (O).
For a dyslexic developer this is not a minor inconvenience. Variable names like l1, Il, or O0 are genuinely hard to distinguish, and the risk of misreading an identifier in a codebase that uses single-letter variable names compounds across thousands of lines per day. Add default line heights that are tighter than any typographer would recommend for prose, and you have an environment that makes sustained reading harder than it needs to be.
The good news is that VS Code exposes almost every relevant typographic setting. You can change the font, the size, the line height, the letter spacing, and the rendering of whitespace — all without a plugin, just via settings.json. And the changes apply immediately, so iteration is fast.
Choosing a font
The font is the single most impactful change. For dyslexic developers the priorities are: clear disambiguation of visually similar characters, a generous x-height, and consistent stroke weight. Ligatures (the merged character pairs like => or != that many coding fonts offer) are worth evaluating separately — some readers find them helpful as they remove ambiguity; others find the merged shapes confusing. The safest default is to disable ligatures initially and turn them on later if you miss them.
JetBrains Mono
Released by JetBrains in 2020, this is probably the best default choice for dyslexic developers who want a standard-looking coding font. JetBrains Mono was designed explicitly around readability: its letterforms are wider than most monospaced fonts, the x-height is tall, and the characters that most often cause misreadings — l, 1, I, 0, O, b, d — each have distinctly different shapes. The numeral one has a serif at the base; the capital I has horizontal serifs that the lowercase L does not. It is free, and VS Code will use it if it is installed on the system.
Fira Code
Fira Code is a widely used coding font derived from Mozilla's Fira Mono. Its letter disambiguation is good — the zero is slashed, and the lowercase L has a slight curve at the foot. It is best known for its programming ligatures, which you can enable or disable independently of the font itself. If you have ever seen != rendered as a single not-equal sign in an editor, that is Fira Code's ligatures at work. For dyslexic readers, test with ligatures off first.
Cascadia Code
Microsoft's own open-source font, designed for the Windows Terminal and VS Code. It has a slashed zero, clear l/1/I disambiguation, and is specifically designed for long-duration screen reading. A lighter-weight variant called Cascadia Mono is also available if you find the regular weight too heavy.
OpenDyslexic Mono
If you have already found OpenDyslexic helpful for prose, the monospaced variant is worth a trial in your editor. The weighted-bottom letterforms that help reduce letter rotation carry over, and the characters most prone to reversal (b/d, p/q) are visually distinct. The trade-off is aesthetic: OpenDyslexic Mono looks substantially different from conventional coding fonts, which can be jarring if you need to share your screen. A more detailed comparison of monospaced options specifically for developers appears in our piece on reading code with dyslexia.
The same set in a font with clear disambiguation avoids the 30-second debug session caused by misreading a single character in a variable name.
The spacing settings that matter as much as the font
Changing the font without adjusting spacing is only half the work. These three settings have a larger effect on sustained reading comfort than most developers realise.
Line height: editor.lineHeight
VS Code's default line height is tight — around 1.3 to 1.4 depending on the font. For dyslexic readers, tighter line spacing increases the chance of the eye landing on the wrong line, a problem that is already amplified in dense code blocks where lines look visually similar. The British Dyslexia Association recommends 1.5 as a minimum for prose; for code, where lines are already shorter and more visually homogeneous, going to 1.6 or 1.7 provides meaningfully better line separation without wasting vertical space. In VS Code the setting is an absolute pixel value (e.g., 24) or a multiplier. If you set it as a multiplier, 1.6 is a solid starting point.
If you want to understand the underlying typographic reasoning, the 2012 study by Zorzi and colleagues — discussed in our article on line and letter spacing for dyslexia — found that increased character and line spacing produced measurable improvements in reading accuracy for dyslexic children, independently of font choice.
Letter spacing: editor.letterSpacing
VS Code exposes letter spacing as a pixel value added to each glyph's advance width. A value between 0.3 and 0.6 gives noticeably more breathing room between characters without making the code look like it is being telegraphed. Beyond 0.8 the spacing starts to break the visual grouping of identifiers, which makes it harder to scan rather than easier. Start at 0.5 and adjust from there.
Font size: editor.fontSize
The VS Code default is 14px. This is serviceable on high-density (Retina) displays but can be taxing on standard 1080p screens where individual pixels are larger and font rendering is coarser. For most dyslexic developers, 15–17px is the practical range — large enough to reduce decoding effort without shrinking the number of visible lines to the point where you lose code context. Our full breakdown of the research behind font sizing is in the article on best font size for dyslexic adults, though that piece is focused on prose rather than code.
Themes: light vs dark for code
The question of whether dark mode helps or hurts dyslexic readers is more nuanced than it first appears — we covered it in depth in the post on dyslexia-friendly dark mode. The short version for editors: light-on-dark themes reduce overall screen luminance, which can lower visual fatigue in a dimly lit room, but dark themes also reduce the contrast between text and background in ways that can make character disambiguation harder, particularly for thin-stroked fonts.
For code specifically, one variable the dark-mode debate tends to overlook is syntax highlighting. A well-chosen dark theme with high-contrast, saturated token colours can actually improve code readability for dyslexic developers because it adds a second disambiguation layer: keywords, strings, variables, and types each get a distinct colour, which means you are not relying solely on letterform recognition to distinguish them. A dark theme where all your tokens render in similar muted colours provides neither contrast benefit nor disambiguation benefit.
Practical theme recommendations:
For light themes: GitHub Light Theme (available as a VS Code extension) is clean and high-contrast, with strong semantic colour differentiation. Quiet Light, which ships built into VS Code, uses softer pastels that some readers with visual stress find less fatiguing.
For dark themes: Tokyo Night has high-contrast token colours and good visual separation between identifier types. One Dark Pro (with the Vivid variant enabled) is another option worth trying. Avoid themes with low-saturation token colours regardless of background mode.
Bracket pair colorization and semantic highlighting
VS Code's bracket pair colorization — enabled via "editor.bracketPairColorization.enabled": true — colours matching brackets, parentheses, and braces in paired colours so that tracking nesting levels becomes a colour-recognition task rather than a count-and-track task. For developers whose working memory load is already high while reading dense code, removing the need to mentally count bracket depths is a genuine benefit. This setting is now on by default in recent versions of VS Code, but worth verifying if you have an older installation.
Semantic highlighting ("editor.semanticHighlighting.enabled": true) goes a step further: it uses the language server's understanding of your code to colour tokens by their actual semantic role (parameter, local variable, property, type parameter) rather than just their syntactic position. Combined with bracket coloring, this means your code has more visual variety, which reduces the visual monotony that makes dense files harder to scan. If you find the extra colours distracting at first, consider enabling only bracket coloring and leaving semantic highlighting off until you decide you want more differentiation.
The minimap: turn it off
VS Code's minimap (the pixel-scale thumbnail of your file on the right edge of the editor) is enabled by default. For most dyslexic developers it provides essentially no benefit — the text is far too small to read — and the moving highlight strip that shows your current viewport position can be a distracting element in the peripheral visual field. If you notice your attention drifting to the right edge of the editor, turning the minimap off ("editor.minimap.enabled": false) removes one source of visual noise.
Word wrap
By default, VS Code does not wrap long lines — they extend horizontally past the visible area, requiring horizontal scrolling. For dyslexic readers this is worth changing. Horizontal scanning is harder than vertical scanning for most readers, and a line that extends off-screen requires you to hold its beginning in working memory while scrolling to its end. Set "editor.wordWrap": "on" to wrap long lines at the editor width. Some developers resist word wrap because wrapped lines can disrupt the visual structure of code; if that bothers you, try "wordWrapColumn": 120 as a compromise — wrapping only at a column wider than most actual lines in your codebase.
Extensions worth installing
Three VS Code extensions that reduce reading load without changing how the editor works:
Indent Rainbow colourises indentation levels with alternating pale background colours — each indentation depth gets a different tint. For Python code in particular, where indentation is semantically meaningful, this makes block structure visible at a glance rather than requiring you to count spaces. It is available in the VS Code marketplace by searching "Indent Rainbow."
Error Lens moves error and warning messages inline, directly beside the offending line, rather than requiring you to hover over a red squiggle to see the message. This reduces the re-reading required to locate and understand an error: instead of reading the line, moving to the Problems panel, reading the message, and returning to the line, you read both in one fixation. For developers whose regressions (eye movements back to re-read content) are already elevated, reducing cross-panel navigation is a meaningful usability improvement.
Bookmarks lets you mark any line with a keyboard shortcut and jump back to it instantly. Losing your place in a large file — particularly after switching to a browser tab to check documentation — is one of the most common friction points for dyslexic developers. Having a lightweight "I was here" mechanism that does not require opening an outline or scrolling removes that friction.
Reading documentation in the browser
Every developer spends a significant portion of their day reading documentation — MDN, docs.python.org, the AWS docs, GitHub readmes, Stack Overflow answers. Unlike your editor, you have no typographic control over those sites by default. They render in whatever font, size, and spacing the site designer chose, which is often body-copy-optimised rather than dyslexia-optimised.
LexiFont applies your preferred dyslexia-friendly font — OpenDyslexic, Lexend, Atkinson Hyperlegible, or others — to every website in Chrome with a single click. If you have spent time configuring your editor to use JetBrains Mono with comfortable spacing, applying the same logic to the documentation sites you read every day is the natural next step. The Pro version lets you customise font, size, line height, and letter spacing per-site, so you can have different settings for MDN versus a dense technical PDF opened in the browser.
A ready-to-paste settings block
Open your VS Code settings JSON (Ctrl+Shift+P → "Open User Settings JSON") and paste the following block. It incorporates all the changes discussed in this article with conservative defaults — adjust font size and line height to taste after a day of use:
The renderWhitespace: "boundary" setting shows whitespace dots between tokens but not within them, which helps spot accidental double spaces in identifiers without covering the editor in visual noise. Remove it if you find it distracting.
A note on "renderWhitespace": some dyslexic developers find whitespace rendering helpful because it makes indentation and spacing errors visible as soon as they are introduced, avoiding the later misread. Others find the dots add visual clutter to an already busy display. Give it a week before deciding either way — initial reactions to new editor configurations are often misleading.
Testing your changes
After making the changes, spend a full working session in the new configuration before evaluating it. Your visual system adapts to typographic environments over hours, not minutes, and the initial unfamiliarity of a new font or line height often resolves into genuine comfort once you have read several thousand lines in it. If after two days a specific change is still making you more uncomfortable, revert that change and keep the others. These settings are independent — you do not need to use them as a bundle.
If you find font choice difficult to evaluate in isolation, try reading the same 100-line file in your original font and then in a candidate font. Pay attention to how often you re-read a line you have just read, and how quickly you can locate a specific identifier when scanning rather than reading. Those two signals — regression rate and scan speed — are more useful than a general sense of whether the font "looks right."
For the browser half of your workflow — documentation, GitHub, Stack Overflow — take the same experimental approach. Install LexiFont, apply a font for a day, and note whether the friction of reading API references goes up or down.
Further reading
- Reading code with dyslexia — Fira Code, JetBrains Mono, and OpenDyslexic Mono in the browser
- Line and letter spacing for dyslexia — what the research actually says
- Dyslexia-friendly dark mode — does inverted contrast actually help?
- Reading GitHub with dyslexia — a practical setup
- Reading Stack Overflow with dyslexia — a setup that helps