Blog · September 27, 2026

Where to break a headline that runs two lines.

Every two-line headline contains one design decision that almost nobody makes deliberately: where line one ends. Leave it alone and the renderer decides, using the only rule it has — fit as many words as the box allows, then break at the last space. That rule knows nothing about your sentence.

The break is punctuation you didn't type

A line break forces a micro-pause. Readers land on the end of line one, drop, and resume. If that pause falls between words that belong together, the sentence has to be re-assembled in the reader's head before it means anything — and on a store listing you have well under a second before they scroll.

Take a real headline: Know where your money goes. There are four places it can break, and they are not equivalent.

Know where your      <- breaks mid-phrase, "your" dangles
money goes.

Know where           <- breaks on the clause, both halves stand alone
your money goes.

Know where your money  <- the good part lands on line two, too late
goes.

Only the middle one breaks where a person speaking the line would pause. That is the whole technique: read the headline out loud, notice where you take a breath, and put the break there. Prepositions, articles and possessives (of, the, your, a) belong to the word after them — never end a line on one.

The two lines have a shape, and it's visible

Once the break sits in the right place, look at the block as a silhouette rather than as words. Two lines of centred display type read as one object, and the object has proportions.

Three shapes work. A long first line over a distinctly shorter second reads as deliberate and settles the eye. Two lines of near-identical length read as a solid block, which is fine when they really are near-identical. A short first line over a long second is the hardest to pull off but can work as a lead-in — "Finally:" over the payload.

The one that always looks like an accident is the near-miss: line two about 85–95% of line one. It isn't different enough to be intentional and isn't equal enough to be a block, so it just reads as sloppy. If you land there, push words across until the difference is obvious in either direction.

Never leave a word standing alone

The classic failure is a second line holding one short word. In 60px type on a screenshot, a lone "goes." under a full-width line is not a typographic nuance — it's the first thing anyone notices, and it makes the frame look unfinished.

The fix is a non-breaking space, not a smaller font. Glue the last two or three words together so the renderer must take them as a unit and wraps earlier:

<h1>Know where your&nbsp;money&nbsp;goes.</h1>

This is also the right tool for names, prices and units that must never split — $4.99&nbsp;/&nbsp;month, iPhone&nbsp;17&nbsp;Pro, 12&nbsp;GB. A number separated from its unit across a line break is a genuine comprehension bug, not a style preference.

Display type doesn't hyphenate

Hyphenation is a body-copy device for narrow columns, where the alternative is a river of whitespace. At headline sizes it is always wrong: the hyphen is enormous, it draws the eye to the least interesting part of the line, and it makes the word take two beats to read. If a word is too long for the box, the box is too narrow or the type is too big — pick one and fix it. Set hyphens: none on your display styles so an inherited stylesheet can't surprise you.

What CSS will do for you, and what it won't

For anything that reflows — your landing page, in-app headings — you can't hand-set every break, so lean on the browser.

text-wrap: balance evens out line lengths across a short block and is the single highest-value line of CSS you can add to a heading. It became newly available across browsers in late 2024, and because balancing is expensive, engines cap it: Chromium applies it to blocks of roughly six lines or fewer, Firefox around ten. Headings are exactly the case it was built for.

text-wrap: pretty targets the other problem — the one-word last line in a paragraph. Support is narrower (Chromium and Safari 26; not Firefox at the time of writing), and the implementations differ in ambition: Chromium adjusts only the final few lines, while WebKit re-evaluates the whole paragraph. Both degrade to normal wrapping, so it's safe to ship.

h1, h2, .headline { text-wrap: balance; hyphens: none; }
p                 { text-wrap: pretty; }

What neither does is understand your sentence. balance optimises line lengths; it will happily produce "Know where your / money goes." because that's the evener split. So: balance as the floor for everything, non-breaking spaces where the meaning matters.

In a screenshot, you have no excuse

Store screenshots are the easy case and the most often botched one. The output is a fixed-size raster — 1290×2796 and nothing else — so there is no reflow, no unknown viewport, no user font scaling. The break you choose is the break every visitor sees, forever. Type the newline yourself rather than tuning the box width until it happens to wrap where you wanted.

Two things to watch once you do. An explicit break is invisible to your layout code, so a later change to font size, padding or device frame can leave a hand-set line uncomfortably short — re-check the frame, don't trust the string. And if you're generating headlines with an LLM, ask it for the text only and place the break yourself; models are unreliable about character budgets, and a model-chosen \n is a coin flip.

Then someone translates it

A break tuned by ear in English does not survive translation. German and Finnish compounds arrive as single long unbreakable words. Japanese doesn't use spaces at all, so the wrap points are completely different rules. Right-to-left locales flip the rag. Your careful two-line balance can come back as three lines with one word on the last.

The workable policy: hand-set breaks only in the locales you can actually read, and for the rest let the box wrap automatically with balance and enough headroom in the layout to absorb a third line without colliding with anything. Then look at the rendered frames — a localised set nobody eyeballs is where these bugs live.

The ten-second check

Shrink the frame to thumbnail size, or just blur your eyes at it. At that scale you can't read the words, which is the point — you see the shape, and a bad rag, a lone word or a near-miss pair of lines is instantly obvious. Then read it aloud once to confirm the pause falls where you'd breathe. That's the entire review.

Quick audit: does line one end where you'd pause speaking? Is any line ending on of, the, your, a? Is there a one-word line? Are the two lines clearly different lengths or clearly equal — not 90%? Any hyphen in display type? Is text-wrap: balance on every heading that reflows? Do your number-and-unit pairs use a non-breaking space? Have you looked at a translated frame?

Where we sweat this so you don't

ShotCanvas templates measure the headline before they lay the frame out, so a three-line translation reflows the composition instead of colliding with the device, and every headline field takes an explicit line break you can place by hand. Drop in your screens, type the words, put the break where you'd breathe, and export pixel-exact frames for every App Store and Google Play slot.

Set your headlines in Studio → Why “perfectly centered” looks off