How to Design Readable Typography for Mobile Screens?

You open your own site on a phone while standing on a train. The headline wraps into five lines and pushes the first paragraph below the fold, the body text is a thin 14px gray that disappears in daylight, and the inline links are so close together that you hit the wrong one twice. On a 27-inch monitor the same page looked polished. This gap between desktop mockups and real handheld reading is where most sites lose their mobile audience, and mobile is usually more than half of the traffic.

This article walks through the specific decisions that make text readable on small screens: the viewport setup, base font size, line height, line length, heading scale, contrast in bright light, touch targets for text links, and how to test the result on real devices.

What Makes Mobile Typography Different?

Mobile typography is not desktop typography shrunk down. Several physical conditions change at once:

Factor	Desktop	Mobile
Viewing distance	50–70 cm	25–40 cm
Viewport width	1280–2560 CSS px	360–430 CSS px
Pixel density	1x–2x	2x–3x
Lighting	Mostly controlled indoor light	Sunlight, dim rooms, glare
Input	Precise mouse pointer	A finger roughly 9–10 mm wide
Reading posture	Seated, steady	Walking, one-handed, interrupted

Because phones are held closer, a 16px font on a phone actually appears at a similar angular size to 18–20px on a desktop monitor. That's why 16px works as a mobile baseline even though it can feel small on a big screen. What phones lack is width: you have roughly 320–400 CSS pixels for text after padding, so every decision about size and spacing has to respect that constraint.

The three properties that matter most are size (can the reader resolve the letters?), measure (how many characters fit per line?), and spacing (can the eye find the next line?). Get those right first, then handle contrast and interaction.

Start with the Viewport Meta Tag

None of your type decisions apply correctly if the browser renders the page as a 980px-wide desktop layout and scales it down. Every page needs this in the head:

<meta name="viewport" content="width=device-width, initial-scale=1" />

Do not add maximum-scale=1 or user-scalable=no. Blocking pinch zoom fails WCAG 1.4.4 (Resize Text), and iOS Safari ignores those values anyway for accessibility reasons. If you were adding them to stop iOS from zooming into form fields, fix the real cause instead: set form inputs to at least 16px.

input,
select,
textarea {
  font-size: max(16px, 1rem);
}

iOS Safari zooms into any focused input whose computed font size is below 16px. Making inputs 16px or larger removes the zoom without disabling it for users who need it.

In Next.js App Router you don't write the meta tag by hand. Export a viewport object from your root layout:

// app/layout.tsx
import type { Viewport } from "next";

export const viewport: Viewport = {
  width: "device-width",
  initialScale: 1,
};

Choose a Base Font Size of at Least 16px

16px (1rem by default) is the floor for body text on mobile, not the target. Many reading-focused sites use 17–18px on phones. The right number depends on the typeface's x-height: a font with a large x-height like Inter or Atkinson Hyperlegible reads comfortably at 16px, while a font with a small x-height like Garamond may need 18px to look the same size. That's why two fonts at the same pixel size can look very different.

Set the size in rem so it respects the user's browser font setting:

html {
  /* Leave the root at the browser default (usually 16px). */
  font-size: 100%;
}

body {
  font-size: 1.0625rem; /* 17px at default settings */
  line-height: 1.6;
}

@media (min-width: 48rem) {
  body {
    font-size: 1.125rem; /* 18px on tablets and up */
  }
}

Avoid setting html { font-size: 62.5%; } to make math easier. It shrinks every unspecified size on the page and makes third-party components render at 10px. For the full argument, see why you should use rem instead of px.

Secondary text deserves attention too. Captions, metadata, and footnotes often drop to 12px on mobile, which is too small for many readers. Keep them at 14px (0.875rem) or above.

Set Line Height for Narrow Columns

Narrow columns need slightly less leading than wide ones, because the eye's return trip to the next line is short. But mobile also adds motion and glare, so you don't want text cramped either. A good starting range:

• Body text: 1.5–1.7
• Headings: 1.1–1.3
• UI labels and buttons: 1.2–1.4

Use unitless values so the line height scales with font size:

body {
  line-height: 1.6;
}

h1,
h2,
h3 {
  line-height: 1.2;
}

A unitless 1.6 multiplies whatever font size each element has. A value like 24px would be inherited as a fixed number and cause overlapping lines when a heading is larger. Also keep WCAG 1.4.12 in mind: users must be able to override line height to 1.5 and paragraph spacing to 2 times the font size without content being clipped. If your containers have fixed heights, that override will break them.

Control Line Length on Small and Large Phones

The usual comfortable range is 45–75 characters per line, with about 66 often cited as ideal. On a phone you're almost always at the low end. A 375px-wide screen with 16px of padding on each side and 17px text gives you roughly 38–45 characters per line, depending on the font.

That means your main lever on mobile is horizontal padding. Too much padding (32px per side) drops you into the low 30s, where lines break constantly and reading becomes choppy. Too little (8px) makes text touch the edges of the screen and feel cramped. A 16–20px gutter is the sweet spot for most phones.

.prose {
  max-width: 68ch;
  margin-inline: auto;
  padding-inline: clamp(1rem, 4vw, 1.5rem);
}

The ch unit caps the measure on tablets and desktops, while the clamp() padding keeps the gutter at 16px on small phones and grows it gently on larger ones. If you want the details on measuring and tuning this, the post on ideal line length for web content goes deeper.

Scale Headings Down for Mobile

A desktop H1 at 56px will occupy half a phone screen when it wraps to four lines. Headings need a tighter scale on mobile, and they should grow smoothly as the viewport widens.

A ratio of about 1.2 (minor third) works well on phones, while 1.25–1.333 suits desktops. Here's a practical set using clamp():

:root {
  --step-0: clamp(1.0625rem, 1rem + 0.25vw, 1.125rem);
  --step-1: clamp(1.25rem, 1.15rem + 0.5vw, 1.5rem);
  --step-2: clamp(1.5rem, 1.3rem + 1vw, 2rem);
  --step-3: clamp(1.75rem, 1.4rem + 1.75vw, 2.75rem);
}

h1 { font-size: var(--step-3); }
h2 { font-size: var(--step-2); }
h3 { font-size: var(--step-1); }
body { font-size: var(--step-0); }

Each value mixes a rem component with a vw component, so it still scales when users zoom or change their default font size. A pure vw value would not, and that fails WCAG 1.4.4. The full technique is covered in fluid typography with CSS clamp().

Two more heading rules for mobile:

1. Balance headline wraps. text-wrap: balance evens out line lengths so you don't end up with a single orphaned word on the last line. It's supported in all current major browsers.
2. Break long words. Product names, URLs, and German compound words can overflow narrow screens. Add overflow-wrap: anywhere on headings or use hyphens: auto with a correct lang attribute.

h1,
h2 {
  text-wrap: balance;
  overflow-wrap: anywhere;
}

p {
  text-wrap: pretty;
}

Pick Typefaces That Survive Small Sizes

Some typefaces that look elegant on a desktop hero fall apart at 16px on a phone. Look for these traits:

• Generous x-height, so lowercase letters are large relative to the font size.
• Open apertures on letters like c, e, and a, so they don't close up into blobs.
• Distinct letterforms for I, l, 1 and O, 0.
• Moderate stroke contrast. Very thin hairlines (as in Didot or Bodoni) vanish on small screens and in sunlight.
• Regular weight of 400 or heavier. Light (300) and thin (100–200) weights look fashionable in mockups and fail in daylight.

Sans serifs such as Inter, Source Sans 3, Atkinson Hyperlegible, and the system UI fonts (SF Pro on iOS, Roboto on Android) work reliably. Sturdy text serifs like Source Serif 4, Literata, and Merriweather also hold up well because they were designed for screens.

Consider using a system font stack for UI chrome on mobile. It costs zero bytes and matches the operating system the user already reads all day.

body {
  font-family: system-ui, -apple-system, "Segoe UI", Roboto, sans-serif;
}

Design Text for Sunlight and Dark Mode

Mobile users read outdoors, where glare washes out low-contrast text. WCAG 1.4.3 requires 4.5:1 contrast for normal text and 3:1 for large text (24px regular or about 18.66px bold). On mobile, treat those numbers as the minimum and aim higher for body copy, around 7:1, which matches the AAA level.

A common failure is light gray body text like #999999 on white, which is only about 2.8:1. Use something closer to #374151 or darker.

:root {
  --text: #1f2937;       /* ~14.7:1 on white */
  --text-muted: #4b5563; /* ~7.6:1 on white */
  --bg: #ffffff;
}

@media (prefers-color-scheme: dark) {
  :root {
    --text: #e5e7eb;
    --text-muted: #9ca3af;
    --bg: #111827;
  }
}

In dark mode, avoid pure white on pure black. The extreme contrast causes halation, where bright letters seem to bleed into the background, especially for users with astigmatism. Off-white on very dark gray is easier on the eyes.

Make Text Links and Interactive Text Tappable

Inline links in body text are hard to hit on touch screens. WCAG 2.2 criterion 2.5.8 (Target Size, Minimum) requires 24×24 CSS pixels for targets, though inline links within a sentence are exempt. Even so, you can make them easier to use:

• Underline links in body text. Color alone isn't enough, and on a phone in sunlight color differences are even harder to see.
• Thicken and offset the underline so it doesn't cut through descenders.
• Increase spacing between stacked links in navigation, footers, and tag lists to at least 44px tall, which matches Apple's Human Interface Guidelines.

a {
  text-decoration-thickness: 0.08em;
  text-underline-offset: 0.18em;
}

.footer-links a {
  display: inline-block;
  min-block-size: 44px;
  padding-block: 0.625rem;
}

Test on Real Devices, Not Just DevTools

Browser device emulation gets the viewport width right, but it doesn't reproduce viewing distance, pixel density, glare, or the feel of a thumb. Use this checklist:

1. Read a full article on an actual phone, ideally both an iPhone and a mid-range Android device.
2. Take it outside. Read the page at full brightness in daylight and at low brightness in a dark room.
3. Increase the system font size. On iOS, go to Settings, Display & Brightness, Text Size. On Android, go to Settings, Display, Font size. Check that nothing overlaps or gets clipped.
4. Pinch zoom to 200% and confirm that text reflows or remains readable.
5. Rotate to landscape, where lines suddenly become much longer.
6. Run Lighthouse in mobile mode to catch tiny text and low contrast automatically.

If your site has a lot of low-vision readers, the more thorough approach in testing typography for low-vision users is worth following.

Mobile Typography FAQ

Conclusion

Readable mobile typography comes down to a handful of decisions made deliberately: a correct viewport, body text of at least 16px in rem, unitless line height around 1.6, sensible side padding that keeps 35–45 characters per line, a tighter heading scale, and contrast that holds up outdoors. None of these is complicated on its own, but skipping any one of them is enough to make a page frustrating on a phone.

The other half of the job is testing in the conditions your readers actually face. Put the page on a real device, take it into sunlight, crank up the system text size, and zoom in. If the text still reads comfortably after all of that, your mobile typography is doing its job.

Here are some useful references for going deeper on mobile typography:

1. MDN Web Docs: Viewport meta tag — how the viewport tag controls layout width and scaling on mobile browsers.
2. W3C WCAG 2.2: Understanding Success Criterion 1.4.4: Resize Text — why users must be able to zoom text to 200%.
3. web.dev: Responsive web design basics — Google's guide to viewports, sizing content, and legible text on mobile.
4. Butterick's Practical Typography: Line length — a concise argument for keeping lines in a readable range.
5. Next.js Docs: generateViewport and the viewport export — how to set viewport options in the App Router.