Word wrap in Microsoft Word flows text to the right margin of the page or the column width of the surrounding text box, not to a fixed character count — so if you need every line to end at exactly 72, 80, or any other column, the wrap has to happen before the text reaches Word. MS Word does not expose a "wrap at character N" setting the way older terminal editors did. Word reflows paragraphs visually as you type and as the page layout changes, and the only practical way to get predictable, character-counted line endings inside a Word document is to wrap the text first in a tool that respects fixed widths and then paste the result. The Word Wrap / Line Length Formatter does exactly this: paste text in, pick a width from 8 to 500 characters, choose soft breaks at word boundaries or hard breaks at the exact column, and copy out text where every line ends where you told it to. That result pastes into MS Word as pre-formatted content with the line breaks you specified, so each line lands on its own visual row regardless of Word's own margin, zoom level, or window size. This is the method used for commit messages, mailing list replies, code comments, and any plain-text block that has to survive Word's automatic reflow.
The phrase "wrap in MS Word" pulls in two unrelated features under the same name. This article covers the second one: controlling the character width of each line so plain-text content keeps its shape after it lands in a Word document.
Two meanings of "wrap" inside Microsoft Word
The first meaning is the layout feature you find on the Picture Format or Shape Format ribbon: Wrap Text, with choices like "Square," "Tight," "Through," "Top and Bottom," and "Behind Text." That feature positions a picture or shape and decides how the surrounding paragraph text flows around it. It has nothing to do with line length.
The second meaning is the line-breaking behavior Word applies to every paragraph in the document: as you type, Word breaks the line at the right edge of the text area and starts a new line, then reflows the whole paragraph when you edit, resize the window, or change the page setup. This is the "word wrap" inherited from text editors, and it is the one people mean when they ask how to make every line end at a specific character count.
Word's built-in word wrap is visual and dynamic: the same paragraph can reflow to 60 characters on a narrow window and 95 on a wide one. For documents that have to look the same everywhere — commit messages archived in plain-text logs, mailing list replies with quoted prefixes, code comments inside source files — that visual wrap is the wrong tool. What you want is a wrap that produces hard, predictable line endings, and that is what fixed-width wrapping gives you.
Why fixed-width wrapping still matters in Word documents
Several plain-text conventions still expect lines to stay under a specific column, and Word documents are often the last place that text is stored before it gets emailed, archived, or pasted into a code review.
- Email bodies. The internet message format standard says each line of a message should be no more than 78 characters, and wrapping body text at 72 leaves room for quoting levels to be added without forcing a re-wrap.
- Mailing list replies. Each level of quoting prepends one or more characters to every line, so the original message has to start short enough to absorb those prefixes.
- Git commit messages. Widely followed Git practice wraps commit body text at 72 columns so the message survives indented display in git log, code review tools, and terminal clients.
- Code comments and source files. The classic 80-column terminal width is still referenced by code style guides, and comments that exceed it break across editors that render at exactly 80 columns.
- Man pages, READMEs, and plain-text archives. Anything distributed as raw text reads best at fixed widths that match the readers' terminals.
The Pro Git book documents the 72-column commit body convention on its Contributing to a Project page, and the POSIX specification for the fold utility, which historically wrapped text on Unix systems, is documented by The Open Group at 80 columns by default.
How to wrap text at a fixed column width for MS Word
This is the practical workflow for getting text into an MS Word document with predictable, character-counted line endings.
- Open the Word Wrap / Line Length Formatter in your browser and paste the source text into the input box. Nothing is uploaded; the tool runs locally in the page.
- Pick a width. Click the 72 preset for email bodies and commit messages, 80 for classic terminal output and code comments, 100 for modern terminals and READMEs, 120 for wider documentation, or type any integer from 8 to 500 directly.
- Choose a wrap mode. Soft wrap breaks at the last space that fits, so no word is ever cut. Hard wrap breaks at the exact column, which is what you want when every line must be under the limit no matter what. Indentation handling and reflow are separate toggles on the same panel.
- Leave reflow on if the text is already wrapped at a different width. Reflow joins the existing line breaks inside each paragraph before wrapping, so old 60-column text re-wraps cleanly at the new width. Switch reflow off when the existing line breaks are meaningful — poetry, source code, address lists — and you want each line wrapped on its own.
- Check the longest-line stat the tool reports after the wrap. If the longest output line is at or under your chosen width, the wrap is clean. The tool also reports how many overlong words were left intact so nothing silently exceeds your limit.
- Copy the wrapped result and paste it into MS Word. In Word, set the paragraph to a monospaced font if the content is code or terminal output, or to a proportional font if it is prose — the line breaks you pasted are preserved as paragraph marks, so each line ends where you specified regardless of Word's own margins.
For content that will be displayed in Word in a proportional font at a non-default font size, paste into a fixed-width text box or use a table cell with explicit width so the line endings still align with the original column boundaries.
Soft wrap versus hard wrap for Word documents
The choice between soft and hard wrap is about what to do when a word is longer than the chosen width. The two modes trade word integrity for line-length strictness, and the right choice depends on the destination.
| Mode | Behavior at the limit | Best for |
|---|---|---|
| Soft wrap | Breaks at the last fitting space; overlong words stand alone on their own line and are reported in the result. | Prose, commit messages, email bodies, documentation — anywhere that cutting a word would be wrong. |
| Hard wrap | Breaks at the exact column, but never in the middle of an emoji or any other two-code-unit character. | Strict terminal output, fixed-column logs, or any destination that requires every line under a hard character limit. |
Soft wrapping is idempotent: running the same soft-wrapped output through the tool again at the same width produces the same lines, which makes the operation safe in repeated pipelines. Hard wrapping does not have this property by construction, because the new exact-column cut point can land inside a word that soft wrap would have left whole.
Standard wrap widths and what each one is for
The presets the tool ships with — 72, 80, 100, 120 — are the ones that named conventions actually use. Picking the right one means matching the destination, not just guessing.
| Width | Source or convention | Best for |
|---|---|---|
| 72 | Widely followed Git commit body convention; traditional email wrap. | Commit messages, mailing list replies, quoted email bodies. |
| 78 | RFC 5322 "should" limit for message lines. | Email bodies at the standard limit. |
| 80 | Classic terminal width; POSIX fold default. | Code comments, terminal output, plain-text documentation. |
| 100 | Modern terminal default in many shells. | READMEs, modern documentation, longer prose. |
| 120 | Modern wide-document convention. | Wide documentation, design docs, long-form prose. |
| 998 | RFC 5322 absolute maximum for message lines. | Edge case — almost never the right choice. |
The 72-column habit for commit messages is documented in the Pro Git book on Contributing to a Project, and the 80-column default for the Unix fold utility is documented by The Open Group. Any width from 8 to 500 characters can also be typed in directly if none of the presets match the destination.
Indentation, quoting, and overlong words in MS Word paste
Three things tend to break a fixed-width paste inside Word: indented blocks that drift off alignment, quoted-email prefixes that grow on every reply level, and long URLs that force ugly breaks. The formatter handles each of these explicitly.
Indentation is preserved and counted against the width. A paragraph that starts with four spaces keeps those four spaces on every continuation line, and the effective wrap width subtracts them, so indented blocks stay aligned instead of drifting right as the paragraph reflows. Quoted-email prefixes made of angle brackets — > or >> — are treated as indentation under the same rule, so replies keep their quoting structure when they are wrapped.
Overlong words stand alone. Soft wrap never cuts a word. Anything longer than the width — a long URL, an unbroken identifier, a hash with no spaces — stands alone on its own line, and the tool reports how many such words were left intact so nothing silently exceeds your limit. The result distinguishes "no line longer than N" from "no word longer than N," which is the distinction that matters when the destination enforces a strict column.
Hard wrap respects surrogate pairs and emoji. Width is counted in Unicode code points, and the tool never splits a surrogate pair — the two-code-unit sequence that represents an emoji or any other supplementary-plane character. A naive column cutter that counts code units will cut an emoji in half; this one does not. The one scope boundary the tool states plainly: East Asian full-width characters count as one, and terminal double-width rendering is not simulated, so if the destination is a terminal that renders CJK characters as two columns, the visual wrap may differ from the counted wrap.
Inputs are capped at one million characters and the tool wraps in a single linear pass, so even large pastes return instantly. Because everything runs in the browser, drafts stay on the local machine, which matters for confidential email replies, unreleased code comments, and any other text that should not be uploaded to a server for formatting.