PandaText / Guides / Why the same paragraph wraps differently in Chrome, Safari and Firefox
Why the same paragraph wraps differently in Chrome, Safari and Firefox
We put the same paragraphs in Chrome 156, Safari 27.0.1 and Firefox 159 on one Mac, with the same embedded font, at 17 px in a box 300 px wide. In four of six cases, the browsers ended lines on different words. These are the three most visible.
All three ran in normal windows on a Retina display at 2×, on macOS 27.0.1, in October 2026. The numbers in the pictures come from the browsers themselves. On an iPhone the picture changes: every shipping iOS browser, Chrome included, uses Safari's engine, WebKit.
1. text-wrap: pretty gives Safari an extra line
With text-wrap: pretty, a short paragraph took 7 lines in Safari and 6 in Chrome and Firefox, so it was 24 px taller in Safari. Only the first line matched. Safari moved one or more words on every line after it.
Safari's version looks at the whole paragraph and evens out the line lengths, so it accepts an extra line to avoid a ragged edge. Chrome's version mainly avoids a very short last line, and this paragraph had none, so Chrome wrapped it as usual. Firefox wrapped it the same way, and browser compatibility data lists no Firefox support for pretty. The CSS spec leaves the algorithm to each browser, so none of them is wrong.
2. Safari draws emoji wider
In a line of emoji next to Noto Sans text, Chrome and Firefox fit 11 emoji on the first line and Safari fit 9. All three use the same Apple Color Emoji font, but Safari gives each emoji more width: the whole line measured 412.7 px unwrapped in Safari, 352.7 px in Chrome and 352.6 px in Firefox.
In Chrome, the width also depends on the screen. In headless Chrome at 1×, the same line measured 400.7 px instead of 352.7 px. A chat message or a comment with emoji can wrap differently on a Retina and a standard display, in the same browser.
3. Firefox breaks long URLs in other places
A long URL in a chat or a comment needs overflow-wrap: anywhere, which lets the browser break inside a word when nothing else fits. Chrome and Safari left “Shared link:” alone on the first line and split the year 2026 across two lines. Firefox put “https://” on the first line, kept 2026 whole, and broke the first three lines in different places.
The engines search for a break point differently. Firefox found break points after “https://” and after a slash; Chrome and Safari broke inside “2026”. Only the last line was the same in all three browsers.
The browser is not the only variable
The same browser can lay out differently on another computer. In an earlier test with embedded fonts, Chrome on macOS and Chromium on Linux broke Latin text the same way, but differed in hyphenation, whose dictionaries come from the OS, and in line height: 18.5 px per line on macOS and 18.0 px on Linux with line-height: normal. Emoji and characters your font lacks also come from each system's fonts.
The engines also round differently. Blink and WebKit measure in 1/64 px, Gecko in 1/60 px, so a word that barely fits in one browser can move in another. Keeping one set of breaks lists what a shared engine has to own.
A layout that does not ask the browser to wrap
If a product only has to look right in one browser, test there and accept the others. A document that also opens in other browsers and on phones cannot, so the web build has to stop being a third layout.
PandaText runs its layout on the web as WebAssembly. Chrome, Safari and Firefox paint lines it has already chosen, instead of each wrapping the paragraph. Here is the paragraph from the first test in PandaText, in the three browsers and in the native views on the iPhone, Android and macOS. All six end each line on the same word.
How we tested
One test page with an embedded Noto Sans font, 17 px text, a 24 px line height and a 300 px box. Each browser ran with a fresh profile in a normal window, driven by its own automation interface. The page reads each line back from the browser's text layout.
Six cases were tested. Two broke the same way in all three browsers: a long German compound word and a Japanese paragraph. One differed only slightly: with hyphens: auto, Chrome split “part-icularly” and Safari and Firefox split “par-ticularly”.
See which browser moved the line
- Fix the inputs. Use one hosted font file, a lang attribute, a fixed width and a line-height in pixels.
- Compare on one machine. Open the page in Chrome, Safari and Firefox at the same zoom, and write down how each line ends.
- Test the risky content. Add a line of emoji, a long URL and any text-wrap or hyphens setting you use. These differed most in this test.
- Decide who wraps. If the text must match a native app or another browser, wrap it with one layout and let the browsers paint that result.
Questions
Is text-wrap: pretty safe to use if lines must match?
Not if the line breaks must match across browsers. In this test it gave Safari an extra line, while Chrome and Firefox wrapped the paragraph normally. Use it where a different number of lines does no harm.
Will the same browser version wrap the same on every OS?
For Latin text in a font you host, often yes: in an earlier test, Chrome on macOS and Chromium on Linux matched in every Latin case. Hyphenation dictionaries, line height, fallback fonts and emoji still come from the OS, so lines and heights can still move.
Sources
- WebKit blog: Better typography with text-wrap: pretty
- Chrome for Developers: CSS text-wrap: pretty
- MDN: text-wrap
- MDN: overflow-wrap
- Pretext issue #321: native text layout emulation (Cheng Lou)
Related guides
How to keep the same line breaks on iOS, Android and the web
One note with one font file broke four ways on iPhone, Android, Chrome, Safari and Firefox. What a shared engine has to own to fix that.
Why the same text wraps differently on iOS and Android
One sentence on an iPhone and an Android phone, same size and width. The system font, emoji and line height each changed the result.