Blog · Reading on the web
Reading GitHub with dyslexia
For a lot of people, GitHub is the office. Issues, pull requests, code review, READMEs, release notes, the whole conversation of building software happens there - and it is arguably the hardest single reading surface a dyslexic developer will meet, because it stacks three different kinds of text on one screen. There is ordinary prose in issues and comments, there is code, and there is the diff, which is code rearranged into a format designed for scanning rather than reading. Each one taxes a dyslexic reader in a different way, and each one needs a different fix. The good news is that almost all of those fixes are available to you, and the one that helps most - changing the typeface on the prose - is the one GitHub does not advertise.
The short answer
Treat prose and code as two separate problems. For the prose - issues, pull request descriptions, comments, discussions, rendered READMEs - swap in a dyslexia-friendly font with a browser override, because GitHub does not let you change its typeface. For the code and diffs, keep a monospace font but make it bigger and higher-contrast, and pick a theme you can actually sit with from GitHub's Appearance settings. Then turn on the three accessibility switches that calm the page: link underlines, reduced motion, and paused animated images.
The settings take five minutes. The font swap on the prose is the part most guides skip, and for many readers it is the single biggest comfort gain.
Why GitHub is hard to read with dyslexia
It is worth naming the problem precisely, because GitHub is not one reading task but several pretending to be one page.
The prose is dense and the lines run long. A busy issue thread is a wall of comments, and GitHub lets the text run the full width of a wide monitor. Long lines are hard for any reader to track and harder with dyslexia, because the further your eye has to travel back to the start of the next line, the easier it is to land on the wrong one. This is the same line-length and line-spacing problem that shows up across the web, and it has the same fixes - more space between lines, and a narrower column. We go deep on the spacing half of it in line spacing and letter spacing for dyslexia.
The code is monospace, and that cuts both ways. Every character in a monospace font takes the same width, which is what keeps columns of code lined up. That alignment is genuinely useful - it is how you see that an opening bracket matches a closing one. But monospace also forces wide, evenly spaced letters that some dyslexic readers find tiring over long stretches, and it offers none of the word-shape cues that a proportional face gives you. The trap is to "fix" this by putting a dyslexia font on your code, which breaks the alignment and makes things worse. Code and prose want opposite treatments.
The diff is built for scanning, not reading. A pull request's "Files changed" view strips a change down to red-and-green lines with the surrounding context removed. It is efficient for an experienced reviewer and disorienting for a reader who is already spending effort on decoding, because the narrative - what this change actually does - is exactly what the format hides. The fix here is less about fonts and more about how you move through it.
The font is fixed. GitHub ships its own house sans-serif for the interface and prose, and there is no setting to change it. You are reading those letter shapes whether they suit you or not, and for many dyslexic readers a face with a taller lowercase and clearer, less ambiguous letters is the change that matters more than any other.
Step 1 - the settings GitHub does give you
Click your profile picture in the top right, open Settings, and you will find two panels worth your time: Appearance and Accessibility.
Pick a theme you can sit with. Under Appearance, GitHub offers far more than light and dark. The full list runs Light, Light high contrast, Dark, Dark dimmed, Dark high contrast, and colour-blind-friendly variants for both light and dark. The two worth testing first are the high-contrast options - they push the text-to-background separation up, which helps a lot of readers - and "Dark dimmed", which softens the harsh white-on-black of standard dark mode. Whether dark helps you at all is personal and worth testing rather than assuming; we lay out the trade-offs in dyslexia-friendly dark mode and the colour question in background colours for dyslexia.
Turn on the monospace editor font. Also under Appearance is a "Markdown editor font preference" - tick "use a fixed-width (monospace) font when editing Markdown". When you are writing an issue or a comment that contains a code snippet or a table, monospace keeps everything aligned as you type, which makes mistakes far easier to catch.
Show link underlines. In the Accessibility panel, set link underlines to "Show". GitHub colours its links by default, and colour alone is a weak signal if you are scanning quickly - an underline gives you a second, shape-based cue so links stop hiding in the body text.
Calm the motion. Still under Accessibility, set "Autoplay animated images" to Disabled (or sync it with your system), and let "Motion" follow your system's reduced-motion preference. README files are full of animated GIFs that loop forever in your peripheral vision, and that constant movement pulls your eye off the line you are trying to read. Pausing them by default means they only move when you choose to play them.
| Setting | Where | Set it to |
|---|---|---|
| Theme | Appearance | A high-contrast option, or Dark dimmed - test before deciding |
| Markdown editor font | Appearance | Fixed-width (monospace) |
| Link underlines | Accessibility | Show |
| Autoplay animated images | Accessibility | Disabled |
| Motion | Accessibility | Sync with system (reduced) |
Step 2 - the font swap GitHub will not do for you
Here is the gap none of GitHub's own settings can close: you cannot change the typeface on the prose. You can pick a theme and enlarge the page, but an issue thread, a pull request description, a discussion and a rendered README are all set in the same house font, and for a lot of dyslexic readers the shapes are the thing. A face with a taller lowercase, open letters - the kind where the gap in a c or an e stays clearly open - and less ambiguity between b, d, p and q does more for comfort than any amount of resizing.
The way around it is to read GitHub in your browser and let a font-override extension restyle the page. LexiFont does exactly this - it swaps in a dyslexia-friendly typeface across every site, GitHub included, and your theme and accessibility tweaks from Step 1 still sit underneath. The difference between GitHub's default face and a face built for clarity tends to show up within a paragraph of a long review comment:
Which face suits you is personal. The usual starting points are OpenDyslexic, with its weighted-bottom letters meant to stop b/d/p/q rotating, and the more conventional-looking Lexend, tuned for reading speed. It is worth trying both on a long issue for a few minutes each. Our research-first guide to the best fonts for dyslexia walks through the realistic trade-offs, and the OpenDyslexic in Chrome write-up covers when that particular face earns its keep. If you have never overridden a website's font before, the steps are simpler than they sound - we cover them in how to change the font on any website in Chrome.
The important nuance: a good setup applies the dyslexia-friendly face to the prose and leaves code blocks in a monospace font, because code depends on the alignment monospace gives it. A proportional dyslexia font on a code diff would knock every column out of true. Keep the two apart - that is the whole trick to reading GitHub comfortably.
Step 3 - reading the code and the diff
Code is not prose, and it does not want the same treatment. Here the alignment matters, so you keep monospace - but you can still make it far kinder to read. Watch what happens to a small block of aligned code if the font stops being monospace:
Three things make that block easier to read without touching the alignment. First, size: press Ctrl and the plus key (Cmd and plus on a Mac) to zoom the whole page until the code is comfortable - there is no prize for fitting more lines on screen. Second, the theme: a high-contrast theme from Step 1 sharpens the syntax highlighting, and that colour-coding is genuinely useful, because it gives you a second cue beyond the letter shapes for what each token is. Third, the monospace face itself: if you read code all day, the specific monospace font your system uses is worth choosing deliberately - some are built with disambiguated zeroes, ones and letter shapes precisely so they are harder to confuse. We go through the options for code specifically in reading code with dyslexia, including the monospace faces designed with dyslexic developers in mind.
For the diff view itself, two habits help. Switch from the split (side-by-side) view to the unified view when a change is hard to follow - reading one column top to bottom is less work than bouncing your eyes between two. And when a pull request is large, resist reading it as a flat list of red and green lines. Open the issue or description first so you know what the change is meant to do, then read the diff as confirmation rather than as a mystery to decode. Carrying the intent in your head before you start lightens the working-memory load that the diff format otherwise dumps on you. If holding several moving parts at once is your particular struggle, the wider picture is in dyslexia and working memory.
READMEs, docs and long threads
A rendered README or a docs page is just prose, so your font swap from Step 2 already covers it - but two extra things help on the long ones. GitHub renders documentation across the full width of the screen, and over-long lines are one of the most reliable ways to lose your place. Narrowing the browser window, or using your browser's reader mode where it is offered, pulls the text into a column you can actually track down. The same workflow that rescues any long article applies here; we set it out step by step in how to read long articles with dyslexia.
For a sprawling issue thread, the thing that drains you is not any single comment but keeping track of who said what across forty of them - a classic working-memory tax, and the same one that makes it easy to lose your place halfway down. Collapse resolved review threads so they stop competing for your attention, and read in passes: skim for the decision first, then go back for the detail only where you need it. You do not have to read a thread in the order it was written.
The desktop app, the phone, and the editor
It is worth being honest about where a font swap can and cannot reach. GitHub Desktop and the GitHub mobile app render their own interfaces and ignore browser extensions, so an override cannot touch them. The same is true inside your code editor - though there the editor's own font setting usually lets you choose a clear monospace directly, which is the better lever anyway. The practical rule is simple: route the reading - issues, reviews, discussions, docs - to the browser, where you control the font, and leave the app for the things it does well.
On a phone, you cannot override the font in the GitHub app, but you can still raise the text. The iOS and Android system-wide text-size and bold-text controls reach into the app, and the mobile browser plus an override extension is an option for the reading-heavy sessions. The device-level settings that help everywhere are collected in reading on mobile with dyslexia, and they apply to GitHub as much as to anything else.
Putting it together
The whole setup takes about ten minutes once and then runs itself. In order of payoff:
- In Appearance, pick a high-contrast or dimmed theme, and turn on the monospace Markdown editor font.
- In Accessibility, show link underlines, disable autoplay images, and follow your system's reduced-motion setting.
- Read GitHub in the browser and apply a dyslexia-friendly font to the prose with an override extension - leaving code blocks in monospace.
- For code and diffs, zoom the page bigger, lean on syntax colours, and use the unified diff view when a change is hard to follow.
- For long threads and READMEs, narrow the column, collapse resolved threads, and read in passes rather than top to bottom.
GitHub will never be a calm reading environment by design - it is built to pack a lot of information into a small space, and that density is the point of it for the people who built it. But dense and unreadable are not the same thing, and the difference is almost entirely in your hands once you know which surface needs which fix. The font swap on the prose is the one most people miss, and usually the one they notice most.
Get LexiFont Pro - OpenDyslexic, Lexend, Atkinson Hyperlegible and Comic Neue for $14.99 one-time