To wrap text in a Word document at a fixed column width, paste the text into a plain-text line-length formatter, choose a width in characters (commonly 72 for email and commit messages, 80 for terminals), pick soft wrap at word boundaries or hard wrap at the exact column, then copy the result back into your document. The "column" here is a character count, not inches on a page, because most of the plain-text destinations that care about wrapping — email clients, Git commit message bodies, code style guides, man pages — count characters per line, not visual width. The number 72 is not arbitrary: RFC 5322, the internet message format standard, says message lines should stay within 78 characters and wrapping at 72 leaves room for quoting levels to be added later without re-wrapping the original. The same 72-column habit carried into Git commit messages, where the official Pro Git book recommends wrapping body text so it survives indented display in git log output. Eighty columns is the classic terminal width that style guides still reference. In every case the rule is the same: pick a column count, break the line at the last space that fits, and never let a single line exceed the limit.
Soft Wrap vs Hard Wrap: Which One Does Your Text Need
There are two ways to break a long line of text into shorter ones, and the right one depends on what reads the result. Soft wrap breaks at the last space that fits inside the chosen width. Words stay whole, lines stay roughly the same length, and a slightly narrower or wider window just reflows everything visually without changing the underlying line breaks. This is what email clients and pretty-printers do.
Hard wrap cuts the line at the exact column, even if that lands mid-word, and inserts a literal newline character so the limit is enforced in the file itself. You reach for hard wrap when a downstream tool actually enforces the limit — some mail relays, certain terminal interfaces, plain-text formatters that count bytes per line.
For almost every human-facing destination, soft wrap is correct. The reason is simple: a hard wrap at the exact column will slice through a long URL, a long identifier or, worse, the middle of an emoji. Soft wrap protects against that — anything longer than the limit is left on its own line and counted, so you know it happened instead of discovering a broken link later. A well-behaved hard wrap implementation still refuses to split an emoji or other two-unit character, even when it is cutting at an exact column. Pick soft wrap by default. Switch to hard wrap only when you have evidence the receiving system rejects anything past the limit.
Where 72, 80, 100 and 120 Come From
The numbers are not folklore. They are the widths the standards and style guides actually document, and the same conventions have carried forward for decades because plain text has had fixed-width screens for almost as long as it has had screens at all.
| Width | Where It Comes From | Typical Use |
|---|---|---|
| 72 | Git commit body convention; leaves room for quoting in email replies | Commit messages, mailing-list replies |
| 78 | RFC 5322 SHOULD limit for internet message format lines | Email bodies, plain-text newsletters |
| 80 | Classic terminal width; referenced by longstanding code style guides | Source code, man pages, terminal output |
| 100 | Modern terminal default; common in updated style guides | Source code in wider terminals |
| 120 | Wide terminals; some web and documentation style guides | Long code lines, documentation bodies |
RFC 5322, the internet message format standard, says each line of a message must be no more than 998 characters and should be no more than 78; the 72-column habit predates the standard and is the value that still leaves room for quoting levels to be added later without re-wrapping the original. The same 72-column habit carried into Git commit messages, where the official Pro Git book recommends wrapping body text so it survives indented display in logs. Eighty columns is the classic terminal width that the POSIX fold utility specification still describes. Wider presets (100, 120) reflect modern terminals and updated style guides rather than a documented standard. Beyond the presets, any width from 8 to 500 characters can be typed directly. The presets are one click; the custom field is for when the destination names its own number.
Wrap Text in a Word Document at a Set Column
Microsoft Word's built-in text wrapping controls position objects around paragraphs — they are a layout feature, not a line-length tool. To wrap text at a fixed column you instead work with the plain-text version of the document: paste the text into a browser-based line-length formatter, set the column, and paste the result back.
- Paste the text and pick a width. Open the Word Wrap / Line Length Formatter, drop your paragraph into the input box, and choose 72 for email and commit messages, 80 for classic terminal output, or type your own width.
- Choose soft wrap or hard wrap. Soft wrap breaks at the last space that fits; hard wrap cuts at the exact column. Leave soft wrap on for almost every case.
- Set reflow and indentation handling. Reflow is on by default — it joins existing line breaks inside each paragraph before wrapping, so already-wrapped text re-wraps cleanly. Turn reflow off when existing line breaks are meaningful (poetry, code, ASCII art). Indentation handling is automatic: leading spaces and quote prefixes are preserved and subtracted from the effective width.
- Check the longest-line stat. The result panel reports the longest output line and the number of overlong words left intact. If a paragraph starts with an unindented sentence and the longest line reads 73, the wrap is doing its job.
- Copy the wrapped result. Copy the output and paste it back into your Word document, your commit message buffer, your email draft, or your plain-text file.
Everything runs in the browser. Nothing is uploaded, stored or attached to an account, so the same workflow works for sensitive drafts, internal documentation and everyday prose.
Keep Indentation, Quotes and Lists Aligned When Wrapping
A line-length wrapper that ignores structure produces output that drifts to the right on every continuation line, eventually wrapping an indented paragraph at the wrong column. Three things need to survive a wrap intact: indentation, blank lines and quoted-email prefixes.
Indentation. A paragraph that starts with four spaces keeps those four spaces on every continuation line, and the effective wrap width subtracts them. The wrapped output of an indented block stays aligned to the same column as the first line, instead of drifting.
Blank lines. Blank lines are kept, and each paragraph wraps independently. A multi-paragraph email or commit message keeps its paragraph breaks instead of being merged into one long block.
Quoted-email prefixes. Lines that begin with one or more > characters are treated as indentation under the same rule. When you reply to a message and the quoting level grows from > to >>, the wrapped body keeps its quoting structure without breaking the convention.
Long words. Soft wrap never cuts a word. Anything longer than the limit — a long URL, an unbroken identifier, a hexadecimal hash — stands alone on its own line, and the result reports how many such overlong words were left intact. Nothing silently exceeds your chosen limit.
Width is counted in Unicode code points, so accented Latin letters, Cyrillic and Greek each count as one. East Asian full-width characters also count as one; the formatter does not simulate terminal double-width rendering, which is the one scope boundary worth knowing.
Re-Wrap Already-Wrapped Text at a New Width
The most common reason to re-wrap text is that the original was wrapped at one column and the new destination expects a different one — a 60-column commit body moving to a 72-column convention, or a 78-column email reply moving to a tighter quoted format. The naive approach is to wrap the already-wrapped file directly, which produces ragged output where every short line is wrapped again on its own.
Reflow mode fixes this. With reflow on (the default), the formatter first joins existing line breaks inside each paragraph so the original wrap is undone, then wraps the rejoined paragraph at the new width. The result is a clean re-wrap at the new column. With reflow off, each existing line wraps on its own — which is what you want when existing line breaks are meaningful, such as in code, poetry, ASCII art, or any line-based data where the breaks are part of the content.
Soft wrap is also idempotent: running the output through the formatter again at the same width changes nothing. That makes the tool safe in repeated pipelines — a 72-column wrapped commit body stays at 72 columns after a second pass, so a script can call the same formatter at multiple stages without producing drift.
Input is capped at one million characters and wraps in a single linear pass, returning instantly even at that size. For everything below that limit, the same workflow covers a one-line commit subject, a multi-paragraph release note, and a quoted email thread reply in a single step.
For a deeper look, see How to Clean AI Text Without Rewriting the Words.