A phone screen can be tall and still leave a narrow space for reading. A heading that fits on one desktop line may take several lines on a phone, with the explanation continuing farther down. Extra screen height doesn’t give the words more room across the page.
“Make it bigger” is a reasonable reaction when that text is hard to read, but it leaves the change open to interpretation. You need a starting size, the role of the text, and a clear explanation of what makes the current treatment difficult to use.
For body text, start at 16 CSS pixels because USWDS recommends at least that effective size for most text. Compare a larger setting if the actual font remains hard to read.
Why Fonts at the Same Size Can Look Different
The size setting doesn’t tell you how tall every visible letter will be. One typeface can have taller lowercase letters, wider characters, or heavier strokes than another at the same stated size. Those differences matter on desktop too, but a narrow column gives wider letters less room before the line breaks.
Open the page directly in a phone browser and read a real paragraph, including punctuation, numbers, links, and emphasized words. Compare it with the desktop treatment, without expecting identical line breaks.
If the text looks tiny or cramped, ask to compare a larger size, a different typeface, or a different weight. Don’t choose from a large brand specimen and assume its smaller body text will work equally well.
Some fonts also have optical sizing: their letter shapes adapt for different text sizes, often with sturdier strokes at small sizes. This depends on the font and its settings, not whether the reader is using a phone. MDN’s explanation of optical sizing shows the distinction.
If a phone and desktop look unexpectedly different, ask whether the intended font and weight actually loaded in both. A replacement font can change the letter shapes and spacing, while the browser and display can also affect their appearance. A high-density screen uses more display pixels to draw web content, not necessarily a smaller web font.
Serif fonts aren’t inherently unsuitable for phones. Judge the particular typeface in the actual paragraph rather than treating serif or sans-serif as a guarantee of readability. The U.S. Web Design System’s typography guidance includes both kinds for screen use.
Start Body Text at 16 CSS Pixels, Then Work Up
Use 16 CSS pixels as a practical body-text starting point, then work upward if the actual font and content remain unclear. USWDS recommends at least an effective size of 16 pixels for most text, including body copy. Its emphasis on effective size matters because equal settings don’t give every font equal-looking letters.
For text-heavy pages, GOV.UK offers another concrete reference: its standard body paragraphs use 19 pixels on small and large screens. Its type scale belongs to its own system and typeface, rather than proving that every website should use 19 pixels.
These are contextual starting choices, not a universal optimum or a WCAG minimum. Don’t keep a difficult-to-read font at 16 pixels because the number is supposed to be enough. Compare the actual treatment and the customer’s task before accepting it.
Confirm What the Size Setting Means
Ask the designer or check your builder’s documentation for the text setting and its unit. A CSS pixel is a web measurement, not one physical dot on a phone display. Hardware resolution and measurements taken from a screenshot don’t establish your text’s CSS font size.
If you only have the published page, you can still identify hard-to-read text without knowing its setting. Record the paragraph or instruction and what makes it difficult, then ask the person maintaining the site to confirm the setting before choosing a replacement.
If the builder uses another unit or named settings such as “body” and “small,” ask the designer what size each setting produces. Don’t assume a particular unit always equals 16 pixels or change a site-wide setting before understanding what it controls.
Let Headings Adapt Without Losing Their Hierarchy
A phone heading doesn’t need to match its desktop size. It needs to remain recognizable as a heading and fit without breaking into awkward fragments. Compare the same heading in both layouts, then judge how it leads into the explanation rather than asking for a fixed phone-to-desktop ratio.
Frameworks—the starting styles a development team may build on—show why the behavior can differ:
- Bootstrap 5.3 enables responsive font sizes by default. Its larger headings become gradually smaller as the available width narrows, while its two smallest heading levels stay fixed. Its responsive-font documentation explains that approach.
- Foundation 6.9 uses one heading scale for smaller screens and another from its medium breakpoint upward. Most heading levels switch sizes at that boundary, while the smallest stays the same. Its base typography documentation shows the two scales.
- Tailwind CSS v4 uses a reset called Preflight in its standard setup, making headings inherit the surrounding text’s size and weight until the team supplies heading styles. Responsive heading changes are choices, not automatic defaults. Its Preflight documentation explains why headings start unstyled.
These are framework starting points, not evidence of what your site uses. Teams can customize them, and a breakpoint is a screen-width boundary rather than a synonym for “phone.” Ask the designer what behavior was chosen if the heading loses its prominence or wraps poorly.
The visual size and the heading level in the page’s structure are separate decisions. Ask the team to preserve a sensible heading structure when changing the appearance, rather than choosing a heading level only to get a bigger font.
Judge Supporting Text Separately
Short companion text, such as a photo credit or caption, can be smaller than body copy. USWDS allows smaller text sparingly for those purposes. That doesn’t mean every text item below 16 pixels is a mistake.
A 12-pixel caption is a possible treatment to evaluate, not a recommended size for every caption. Its usefulness depends on the typeface’s proportions, weight, spacing, contrast, and context. If it is difficult to read, compare a larger or clearer treatment rather than defending the number.
Keep essential price conditions, eligibility, hints, and errors readable enough to do their job. Making a headline comfortable won’t help visitors understand a faint, tiny restriction. An instruction needed to correct a form error deserves more attention than a photo credit, even if both are styled as supporting text.
For controls, ask the designer to consider labels, entered text, hints, and errors together. If the error message is hard to read, request a clearer treatment for that message rather than enlarging every setting globally.
Review Paragraphs, Not a Font Specimen
Read several paragraphs in their actual column. Look for lines that feel crowded, phrases broken into distracting fragments, or spacing that makes it hard to follow one line to the next. Ask the designer to adjust the text and layout together rather than squeezing the copy into the old space.
USWDS recommends line height of at least 1.5 times the font size for longer text. Treat that as a practical starting recommendation to compare, not a claim that WCAG requires every site to use that default. Don’t shrink phone text to reach a desktop-oriented line-length target.
An illustrative request could say: “The service explanation feels cramped in this font at 16 pixels. Please compare a larger body setting with more line spacing, keeping the eligibility text readable too.” That describes a useful alternative without prescribing unknown code.
Separate a Comfortable Default From Accessibility Verification
Text can look comfortable at its default size and still have poor contrast or lose content when enlarged. Ask the developer or accessibility specialist to assess contrast and whether content still fits and works after text enlargement or spacing changes. Scaling a visual preview isn’t a text-resize accessibility test.
W3C’s explanation of text resizing describes the relevant requirement and its exceptions. These checks need more than selecting a preferred font size, and a marketer’s visual comparison isn’t a conformance assessment.
Make the Change Specific Enough to Review
Record the text role, example page, and visible problem, plus the typeface and setting if known. Mark unknown details as unknown rather than measuring a screenshot or guessing. Ask the designer to show representative paragraphs, headings, captions, and form states before applying a global change.
Then compare the proposed treatment with the customer’s reading task. Keep a setting because it works for the content and people you’re designing for, not because one number is supposed to make every mobile website readable.
