To wrap a sentence in Word at a fixed column width means breaking the text at a chosen character count so every line stays under that limit — the way email clients, terminals, and commit-message conventions have expected for decades. Word's visual "wrap text" feature moves text around images, which is a different problem solved inside the Word document itself. Column-based line wrapping is what RFC 5322 prescribes for email (lines should be no more than 78 characters), what the POSIX fold utility has done since the early days of Unix, and what most code style guides still recommend at 80 columns. The Word Wrap / Line Length Formatter does exactly that job: paste your text, choose a width, and get back the same words broken at the right places. It handles soft wrap (break at the last space that fits), hard wrap (break at the exact column), indentation, and re-flowing of paragraphs that were already wrapped at a different width, all without uploading anything because the work runs in the browser.
What wrapping a sentence in Word actually means
The phrase "wrap a sentence in Word" can point at two different tasks depending on who is asking. In most search results it refers to Microsoft Word's layout feature for flowing text around pictures, shapes, text boxes and SmartArt. That is a visual, in-document operation that repositions text and changes how an image sits on the page. It is not what this article is about.
What this article covers is the older, plain-text meaning of wrapping: breaking a line of running text at a chosen column so the result fits the conventions of fixed-width reading contexts. That is the wrapping that mail clients do before they send RFC 5322-compliant messages, that Git does when it displays a commit body indented under a header, and that terminals have done since fixed-width screens existed. When the phrase "wrap a sentence in Word" is paired with anything like "72 characters," "80 columns," "commit message," or "plain text," this is the task being asked about, and a column-based formatter is the right tool for it.
Why fixed-column wrapping still matters today
Several established standards still treat line length as a hard contract rather than a style preference. RFC 5322, the internet message format standard, says each line of an email message must be no more than 998 characters and should be no more than 78; the traditional practice of wrapping body text at 72 leaves room for quoting levels to be added without re-wrapping, and the same 72-column habit carried into commit messages, where widely followed Git practice wraps body text so it survives indented display in git log output (see the Pro Git book on contributing to a project). Eighty columns is the classic terminal width that code style guides still reference. Modern style guides often extend to 100 columns for wider displays, with 120 as an upper practical limit.
The practical effect is that the same document may need to be re-wrapped for different audiences: a long paragraph you wrote at 100 characters may need to become a 72-character wrap before you paste it into a commit message, and a manual page written for a terminal may need to drop back to 80 before it ships. Doing this by hand is slow and breaks when paragraphs are long or already partially wrapped. A dedicated formatter does it in one pass and reports the longest output line so you can verify the result.
How to wrap a sentence at a chosen column width
- Paste the sentence or paragraph into the input field on the Word Wrap / Line Length Formatter page.
- Pick a width from the preset buttons — 72 for email body text and commit messages, 80 for classic terminal output, 100 or 120 for modern code and documentation — or type a custom width anywhere from 8 to 500 characters.
- Choose the wrap mode: soft wrap breaks at the last space that fits inside the limit and never cuts a word, while hard wrap breaks at the exact column when every line must be under the cap regardless of word boundaries.
- Set the reflow and indentation options. Reflow, on by default, joins existing line breaks inside a paragraph first so already-wrapped text re-wraps cleanly. Turn it off when existing line breaks are meaningful, as in poetry, addresses, or hand-formatted tables. Indentation handling preserves leading spaces and quote prefixes and subtracts them from the effective width.
- Run the wrap and read the result panel. The tool reports the number of input lines, the number of output lines, and the longest output line. If any word was too long to fit even alone on a line under soft wrap, the count of overlong words is also shown.
- Copy the wrapped output and paste it back into Word, your email composer, your commit editor, or wherever the destination expects fixed-width lines.
Choosing a wrap width: 72, 80, 100, 120 and beyond
| Width | Where it comes from | Best for |
|---|---|---|
| 72 | Email quoting practice; Git commit body convention documented in the Pro Git book | Commit messages, mailing-list replies, text that will be quoted by other replies |
| 80 | Classic terminal width referenced by traditional Unix tools and the POSIX fold specification | Code comments, README excerpts, man-page-style text, anything read in a terminal |
| 100 | Modern code style guides such as Google and LLVM | Source-code comments in contemporary projects, wider documentation |
| 120 | Upper practical limit referenced in modern style guides | Documentation with long identifiers, generated reference text |
Any value between 8 and 500 can be typed directly into the width box; the presets are just the most common conventions. If your destination specifies a different number — a man page that targets a 132-column printer, for example — set that exact value.
Soft wrap versus hard wrap
Soft wrap is the default for almost every reading context. It walks the text from left to right and breaks the line at the last space that still fits inside the limit. The pangram "The quick brown fox jumps over the lazy dog" is 43 characters. Wrapped softly at a 20-character width it becomes three lines:
- Line 1: The quick brown fox — 19 characters, the last space that still fits.
- Line 2: jumps over the lazy — 19 characters.
- Line 3: dog — 3 characters.
Three lines, no word cut, and the original words survive intact. Soft wrapping is also idempotent: running the output through the tool again at the same width changes nothing, which makes the formatter safe to drop into a pipeline.
Hard wrap is the right choice when the destination will not break lines on its own and every line must be under the cap no matter what. Hard wrap cuts at the exact column. The formatter still refuses to split a surrogate pair, so an emoji or any other two-code-unit character will not be sliced in half. A naive column cutter gets this wrong; this one does not. Width is counted in Unicode code points rather than bytes or JavaScript string length, and the tool states its one scope boundary plainly: East Asian full-width characters count as one column, terminal double-width rendering is not simulated.
Keeping structure: indentation, long words, and re-wrapping
Three details separate a real wrap tool from a quick search-and-replace hack. Indentation is preserved and accounted for: a paragraph that starts with four spaces keeps those four spaces at the start of every continuation line, and the effective wrap width subtracts them, so indented blocks do not drift right as they continue. Quoted-email prefixes made of angle brackets are treated as indentation under the same rule, so a reply keeps its > markers on every line.
Long words are protected under soft wrap. A URL, an identifier, or any unbroken string longer than the limit stands alone on its own line. The result panel reports how many such overlong words were left intact, so nothing silently exceeds your limit without your knowledge.
Re-wrapping works. With reflow on, existing line breaks inside a paragraph are joined first, so a 60-column email re-wraps cleanly at 100 columns, and a 100-column document re-wraps cleanly at 72 for a commit message. Blank lines are kept, and each paragraph wraps independently. The tool runs everything in a single linear pass and is capped at one million characters of input.
When to use a formatter and when Word's built-in tools are enough
Microsoft Word's own wrap features — the Wrap Text gallery, the Layout options for images and shapes, the Paragraph dialog's line-break controls — are the right tool when the task is visual layout inside a Word document. They do not, however, enforce the column conventions of plain text. They do not know about RFC 5322, about the 72-column commit-message habit, about quoted-reply prefixes, or about the difference between soft wrap that respects words and a hard cut at column 80.
When the output has to live somewhere other than a Word document — in a commit message, in an email reply that will be quoted by other people, in a code comment that will be read in a terminal, in a man page, in a plain-text README — a column-based formatter is the right tool. Use Word's native features for layout, and reach for a line-length formatter when the constraint is character count per line.