Why Your Body Text Is Probably Too Small

Sixteen pixels for body text is treated as a safe, neutral default across the web, largely because it's been the browser default for decades — not because it's the right size for how most content actually gets read now. Defaults have a way of calcifying into assumptions. Sixteen pixels was set as a browser default in an era of smaller, lower-resolution screens viewed at different distances than most reading happens at today, and the number survived the transition mostly because nobody had a strong enough reason to question it, not because anyone re-derived it from how people actually read.

On the larger, higher-resolution screens most people read on today, 16px body text often sits smaller than comfortable, especially for longer-form content that's meant to be read for more than a few seconds. The mismatch isn't dramatic on any single line — nobody looks at 16px text and immediately calls it illegible. It shows up instead as a low, cumulative fatigue: a slight extra effort per line, repeated across a paragraph, a page, an article, until reading something feels marginally more tiring than it needed to, without an obvious culprit to point to.

It helps to separate two different reading situations that get lumped together under "body text," because they don't actually need the same size. A dense interface — a settings list, a data table, a form — is read in short, targeted bursts, glanced at rather than settled into, and 16px or even smaller can genuinely work fine there. A long-form article, a blog post, an essay meant to be read start to finish, is a different reading mode entirely, closer to a book than a spreadsheet, and it's exactly this second category where the standard default starts to show its age.

Eighteen pixels, sometimes slightly more for long-form articles, tends to hold up better across devices without feeling oversized on a phone. That's worth stating plainly because the instinctive worry runs the other way — that a larger base size will feel clumsy or oversized on a small screen. In practice it rarely does, because the alternative isn't actually neutral: text that's comfortable on a large monitor and slightly small on a phone is a worse trade than text that's comfortable on a phone and merely adequate on a large monitor, given that phones are where most reading now happens.

It's a small change that measurably reduces reading fatigue, and the mechanism behind that is straightforward rather than mysterious. Larger text needs less accommodation effort from the eye per character, reduces the frequency of squinting or leaning in that smaller text quietly demands, and gives letterforms enough size to render their distinguishing details clearly rather than relying on the reader's brain to fill in ambiguous shapes from context. None of these effects is large in isolation. Stacked across a multi-minute read, they add up to a genuinely different experience, even though the size difference on screen looks modest.

The natural pushback is that bumping body text up two pixels changes layout everywhere — line counts shift, containers that were tuned for 16px suddenly wrap differently, and a change that sounds cosmetic turns into a much bigger production task than the size number alone suggests. That's a legitimate cost, not an imagined one. But it's a cost worth distinguishing from the reading experience itself: the layout friction is a one-time migration problem, solvable with normal design and engineering effort, while the readability problem it's fixing is a permanent tax paid by every reader, every time, for as long as the smaller size stays in place.

There's also a fair edge case to raise: not every piece of content wants to grow. UI labels, table data, dense dashboards, and anything meant to be scanned rather than read continuously can genuinely justify staying at 16px or smaller, because the goal there is information density, not sustained reading comfort, and a larger size would just push more of that information off screen for no readability benefit. The case for 18px is specifically a case for long-form reading content, not a blanket argument that every text style on every screen should grow.

Here's what this looks like in practice on a real article page. Body copy at 18px, in a column around 60 to 75 characters wide, paired with a line height around 1.5, produces a block of text that reads noticeably easier than the same content at 16px with a tighter line height — the kind of setup that's still common on sites that never revisited their type defaults after launch. The difference isn't subtle once it's side by side. It's subtle only when there's nothing to compare it against, which is most of the time most readers encounter it.

That comparison is worth doing directly rather than trusting convention: put the same paragraph at 16px and 18px side by side and read both aloud. Most people can feel the difference before they can explain it — a slight easing of effort, a sense of the text meeting them partway rather than asking them to lean toward it. The exercise matters because reading size is one of those judgments that's genuinely hard to make in the abstract but immediate once there's a direct comparison in front of you.

This is also a case where accessibility and general comfort point in the same direction rather than competing. Discussions about type size often get filed under accessibility, as if it were a specialized concern for a subset of readers with specific needs, distinct from how "most people" experience text. Larger, more comfortable body text benefits nearly everyone reading for more than a few seconds, not just readers who need it to be legible at all. Treating it as a niche accommodation rather than a default improvement undersells how broadly the fix applies.

The convention around 16px isn't going to change industry-wide just because one article makes the case against it, and that's fine — the point isn't to declare a new universal default. It's to notice that 16px is a historical artifact being treated as a settled fact, and that the settled-fact treatment is exactly what stops teams from testing it against their own content, on their own devices, with their own readers.

Sixteen pixels earned its place as a default decades ago, under conditions that no longer describe how or where most reading happens. It hasn't earned the unexamined trust it still gets by default today. The fix costs almost nothing to try — set the same paragraph at both sizes, read them back to back, and let the difference make its own case, rather than inheriting a number nobody chose on purpose for the content in front of them.