Font Comfort for Startup Blogs: Why Reading Size Matters
Most startup blogs are harder to read than they need to be. One line of CSS fixes it. Here's what the best reading platforms know about font size that dashboards don't.
There is a silent UX problem on most startup blogs. The content is good. The writing is clear. But something feels slightly off — the text is just a little too small, a little too dense, a little too hard to settle into. Readers notice it without knowing why, and they leave earlier than they should.
The cause is almost always the same: the blog was built on a UI framework designed for dashboards, not for reading. The framework's default font size — optimized for data tables and sidebar navigation — got inherited by the blog without anyone making an explicit decision about it.
What the best reading platforms actually use
The platforms that have spent the most time optimizing for reading comfort have converged on a surprisingly narrow range. This isn't coincidence — it reflects what's known about comfortable reading at typical screen distances.
Body font size by platform
The range for comfortable sustained reading is 18–21px. Below 16px you're optimizing for data density, not readability. The gap between Tabler's default 14px and Medium's 21px is not subtle — it's the difference between content that invites reading and content that requires effort.
Why dashboard frameworks get this wrong for blogs
Tabler is a dashboard UI kit. It was designed for admin interfaces where the primary goal is information density — fitting more data on screen, making UI chrome recede, keeping labels and metadata compact. At 14px, a table with 20 rows and 8 columns fits comfortably on a 1440px monitor. At 20px it doesn't.
That's the right tradeoff for a dashboard. It's the wrong tradeoff for an article. When you inherit a dashboard framework's base font size for blog content, you're importing a design decision that was made for a completely different reading pattern.
Dashboard users scan. Blog readers read. Those two modes require different typographic foundations.
The fix — one line of CSS
The cleanest solution is scoping the font size override to the <article> element. This leaves all Tabler dashboard components — navbars, sidebars, badges, tables — at their intended 14px. Only the reading content gets bumped up.
article { font-size: 1.25rem; }1.25rem at a 16px root resolves to exactly 20px — right in the sweet spot used by Substack and close to Medium's 21px. It's large enough to feel comfortable for sustained reading, without crossing into "this is designed for a 10-foot screen" territory.
The scoping matters. If you set body { font-size: 1.25rem } instead, every Tabler component on the page inherits it — breadcrumbs get huge, sidebar badges balloon, the navbar text becomes oversized. By targeting article, you create a clean boundary: dashboard UI on one side, reading content on the other.
Line height matters as much as size
Font size alone doesn't determine reading comfort. Line height — the vertical space between lines — has an equal impact on how easy it is to track from one line to the next. For reading-optimized content, 1.6–1.75 is the accepted range. Tabler's default is 1.5, which works for UI components but feels slightly compressed for long paragraphs.
Reading comfort: size + line height together
What this means for your startup blog
If your blog is built on Tabler, Bootstrap, or any other dashboard-first framework, the typography decision has probably been made by default rather than by design. The fix is not a redesign — it's a single scoped CSS rule that takes thirty seconds to add and immediately moves your reading experience into the same range as the platforms your readers use every day.
The signal to watch: if readers are spending less than 90 seconds on articles that should take 5 minutes to read, font size and line height are the first place to look. Before you conclude the content isn't engaging, check whether the content is comfortable to read in the first place.