Left-Aligned Text for Readable Web Content

Text alignment is easy to overlook until it makes a page hard to read.

Long paragraphs centered in the middle of a page force readers to hunt for the start of every line. Fully justified text stretches the gaps between words to make both edges straight. Both can make ordinary body copy harder to track, and both become more noticeable on narrow screens, where each line has less room.

For most multi-line body text in English and other left-to-right languages, left alignment is the safest default. Every line starts in the same place, the right edge is allowed to be uneven, and nothing is stretched to fit.

That does not mean every element on a page should be left-aligned. A short heading or callout can work centered, and a price, a date, or a numeric table column can work right-aligned. The question worth asking is whether the reader has to track several lines in a row.

The Simple Rule

Use left alignment for body copy that runs longer than a few lines in left-to-right languages.

Use centered text sparingly, for short self-contained content like a heading, a brief pull quote, an event date, or an empty-state message.

Avoid fully justified paragraphs on the web.

That is most of the advice. The rest of this explains why, and what to check on a page you already have.

See the Difference

Why Fully Justified Text Causes Problems

Justification forces every line to reach both margins. Since the words themselves do not change, the space between them has to absorb the difference, which is why justified paragraphs develop gaps that vary line to line.

W3C’s technique on aligning text on only one side describes the consequence directly. It says that many people with cognitive disabilities have a great deal of trouble with justified blocks of text, because the spaces between words create “rivers of white” running down the page.

WCAG’s Visual Presentation criterion, which is Level AAA, includes a plain requirement: text is not justified. WebAIM’s text layout guidance reaches the same place from the usability side, noting that although justified text may appear more tidy at first, the spacing variations impair readability.

Print handles this differently because typesetters have tools the browser does not use by default. A print compositor can hyphenate aggressively, adjust letter spacing within a line, and rewrite a line that will not fit. A browser justifying a paragraph on a phone has none of that working for it.

Why Long Centered Paragraphs Slow Readers Down

Centered text keeps word spacing even, so it avoids the rivers problem entirely. It moves the cost somewhere else.

WebAIM puts it plainly: long blocks of centered text result in each new line beginning in a slightly different location, which can introduce overhead when reading. The return sweep from the end of one line to the start of the next stops being automatic, because there is no fixed edge to return to.

One centered line costs nothing, since there is no next line to find. The more lines a reader has to track, the more the moving starting point matters, which is why a centered heading reads fine and a centered six-line paragraph does not.

When Centered or Right-Aligned Text Works

Alignment is a tool rather than a rule, and each option has content it suits.

Right alignment in a table column is the case people forget. A column of currency values is easier to compare when the digits line up by place value, and that is a genuine readability gain rather than a stylistic preference.

Text Alignment and Accessibility

Alignment is a visual choice, so it does not change what a screen reader announces. Reading order, semantic headings, labels, and descriptive link text control that experience. A page can be perfectly left-aligned and still be unusable with a screen reader, and changing text-align will not fix it.

Alignment still matters for people reading visually. Justified text can create inconsistent gaps between words, and long centered paragraphs move the start of every line. Both make line tracking harder, and readers with cognitive disabilities are the group W3C names specifically.

For left-to-right body copy, left alignment is the default worth keeping. For right-to-left languages like Arabic and Hebrew, follow the language’s normal reading direction rather than forcing text to the left.

A Practical CSS Pattern

Two properties do most of the work. text-align: start follows the document’s writing direction instead of hardcoding a side, and a maximum line length keeps the return sweep short.

:root {
  --measure: 68ch;
  --body-size: clamp(1rem, 0.96rem + 0.2vw, 1.125rem);
  --body-leading: 1.6;
  --text-color: #1f2933;
  --link-color: #0b5cab;
}

.prose {
  max-inline-size: var(--measure);
  color: var(--text-color);
  font-size: var(--body-size);
  line-height: var(--body-leading);
  text-align: start;
}

.prose :is(p, ul, ol, blockquote) {
  margin-block: 0 1.25em;
}

.prose a {
  color: var(--link-color);
  text-decoration-line: underline;
  text-decoration-thickness: 0.08em;
  text-underline-offset: 0.14em;
}

.prose :is(h2, h3) {
  text-wrap: balance;
}

.prose :is(p, li) {
  text-wrap: pretty;
}

A few notes on why each line is there.

text-align: start resolves to the left in left-to-right contexts and to the right in right-to-left ones, so a single rule serves both. Hardcoding left breaks the moment you add an Arabic or Hebrew page.

max-inline-size: 68ch caps the line length without a fixed pixel width. WCAG’s Visual Presentation criterion asks for no more than 80 characters, so 68 sits inside that with room for the wider characters ch does not account for.

line-height: 1.6 is a reasonable design choice rather than a universal law. Pick what suits the typeface and check it against real content.

text-wrap: pretty is an optional browser hint that can improve paragraph wrapping, including awkward last lines. Browsers that do not support it fall back to ordinary wrapping, so nothing breaks. Treat it as a refinement rather than a readability requirement.

Spacing between paragraphs belongs in the same block as line height. Ideas need room to separate, and a visible gap does that better than adding leading inside the paragraph.

text-wrap: balance suits headings rather than paragraphs. It evens out a small number of lines and stops a heading ending on one stranded word, and browsers cap how many lines it will balance, so it is not a body-copy tool.

Skip letter-spacing and word-spacing adjustments on body copy unless you have a specific reason. Tightening or loosening tracking on a face that was already spaced by its designer usually makes reading worse.

Avoid Fixed Heights Around Text

Text grows. A reader changes zoom, rotates a phone, switches language, or raises their own font and spacing settings, and every one of those makes a block of text taller. A component with a fixed height and hidden overflow looks correct in a design file and clips real content in use.

/* Fragile. Text is clipped when it wraps or when spacing increases. */
.card {
  height: 220px;
  overflow: hidden;
}

/* Resilient. The card grows with whatever it holds. */
.card {
  min-block-size: 220px;
  padding: 1.5rem;
}

A fixed height is not automatically wrong. It becomes risky the moment it contains text a reader can change, which is most text.

Other Text Settings That Matter

Alignment is one part of readable body copy. A perfectly left-aligned paragraph is still tiring if the lines run too long, the type is too small, the contrast is weak, or the lines sit too close together.

The line-length numbers deserve their scope. WebAIM’s text layout guidance says there is no universally optimal number of characters per line, and that fewer than around 50 or more than around 120 will likely introduce difficulty. WCAG’s Visual Presentation criterion sets a tighter ceiling of 80 characters, at Level AAA. Those are two different bars, and neither is the single correct measure.

These settings also interact. A 68-character line feels comfortable in a large open typeface and dense in a small condensed one. Test the page you have rather than treating any number as a rule.

Make Links Look Like Links

In body copy, a link should be identifiable without asking the reader to notice a shift in color. An underline is the clearest default, especially for a link sitting inside a sentence.

W3C’s technique on distinguishing inline links puts a number on the color-only case: the contrast ratio between the link text and the static text around it must be at least 3:1. That is a harder target than it sounds. The blue and near-black in the CSS above both clear 4.5:1 against white, and they reach only 2.2:1 against each other, so color alone would not carry the distinction. The underline is doing the work.

If a design removes underlines, give readers another visible cue that survives without color, and make sure the keyboard focus state is obvious.

.prose a:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

Hover alone is not a cue. A touch screen has no hover state, so anything that only appears on hover is invisible to most mobile readers.

Test It Against a Reader’s Own Settings

This is a useful check that many typography guides leave out. For WCAG AA conformance it is a requirement rather than a preference.

WCAG’s Text Spacing criterion is Level AA. It says no loss of content or functionality may occur when a reader sets line height to at least 1.5 times the font size, spacing after paragraphs to at least 2 times, letter spacing to at least 0.12 times, and word spacing to at least 0.16 times.

Paste this into your browser’s dev tools on any page and watch what happens.

/* A stress test, not production CSS. Nothing should clip, overlap or disappear. */
* {
  line-height: 1.5 !important;
  letter-spacing: 0.12em !important;
  word-spacing: 0.16em !important;
}
p {
  margin-block-end: 2em !important;
}

Fixed-height buttons, cards with clipped overflow, and single-line navigation items are where this usually breaks.

How to Audit a Page in Five Minutes

A narrow viewport is the fastest way to surface several of these at once. 320 CSS pixels works well as a stress test rather than as a device target, and it exposes awkward line breaks, clipped controls, wrapped navigation labels, and anything that disappears when text grows.

One thing to watch on phones. Avoid building a narrow reading column inside an already narrow screen. Modest inline padding is usually enough, and generous side margins can leave only a few words per line, which gives the reader more return sweeps rather than fewer.

The Takeaway

Left alignment is a reliable default for long body copy in left-to-right languages, not a rule for every element on a page.

Center short self-contained content when the design calls for it. Right-align values where the data benefits. Avoid fully justified paragraphs. Then test the result at a narrow width, at high zoom, and with increased text spacing.

The goal is not a tidier right edge. It is making the next line easy to find.

If you want a second pass on your site’s readability and accessibility, Garrett Digital can help you find what is costing your readers effort.