Word wrap at a fixed line width means reformatting plain text so every line stays at or under a chosen column count — typically 72 columns for email and commit messages or 80 columns for terminals and code — and the formatter breaks each line at the last space that fits while never cutting a single word in two. When readers search for "how to format wrap text in Word", they are usually asking about this line-length problem: getting the underlying words in their document to sit on lines of a predictable length before they paste the text into Word, commit it to Git, send it on a mailing list, or display it in a terminal. Microsoft's own "Wrap Text" button is a different feature — it flows text around pictures and shapes — and it does not change the number of characters on a line. For the line-length sense of "wrap text", the practical fix is a plain-text formatter that takes pasted content, applies a chosen column count, and returns the same words broken at the right places. The convention numbers are not arbitrary: RFC 5322, the internet message format standard, says each line of an internet message should be no more than 78 characters and must be no more than 998, and the long-standing 72-column habit leaves room for quoting levels to be added without re-wrapping. Eighty columns is the classic terminal width that code style guides still reference. Both conventions are baked into the Word Wrap / Line Length Formatter as one-click presets alongside 100 and 120.
This guide covers what plain-text wrapping actually is, why 72 and 80 are the defaults, and how to use the formatter step by step, including the soft-versus-hard choice, the reflow option for already-wrapped text, and the way indented blocks and quote prefixes survive the reformat.
What "Format Wrap Text" Actually Means in Plain Text
Plain-text wrapping has nothing to do with pictures. It is the act of inserting line breaks at word boundaries so each line of running text stays under a target character count. Editors, mail clients and terminals have done this since fixed-width screens existed, and plain-text conventions still expect it. Word processors like Microsoft Word reflow paragraphs visually as you type, which is why "wrap text in Word" feels like a non-question to people who use Word every day; the screen wraps automatically. The question only becomes visible when the destination is not Word — when the text is going into a Git commit message, an email reply that will be quoted multiple times, a man-page-style document, a code comment, a banner for a fixed-width display, or a file that another program will read line by line. In all of those places, the line length is set by the file, not by the reader's window, and the only way to control it is to insert hard or soft line breaks ahead of time.
The format-wrap-text job, then, has three inputs: the text to format, a target width in characters, and a wrap mode (soft or hard). The output is the same words with line breaks in the right places, and that is exactly what the Word Wrap / Line Length Formatter produces in a single linear pass.
Standard Line Widths: Why 72 and 80 Are the Defaults
The presets are not guesses. They map to documented standards and long-running practice:
| Width | Typical destination | Where the number comes from |
|---|---|---|
| 72 columns | Email body, Git commit message body lines | RFC 5322 recommends message lines stay under 78 characters; wrapping at 72 leaves room for reply quote prefixes like "> " to be added without re-wrapping. Git commits follow the same habit because the official Pro Git contributing guide recommends wrapping commit body text so it survives indented display in git log. |
| 78 characters | RFC 5322 recommended maximum | The internet message format standard itself calls 78 the line length that "SHOULD" be observed for SMTP delivery. |
| 80 columns | Classic terminals, code style guides | The width of physical terminals through the 1980s and 1990s; the POSIX fold utility specification defaults to 80 and is the reference for hard-wrap behavior. |
| 100 and 120 columns | Modern code style guides, documentation | Wider screens have pushed some style guides to 100 or 120, with 100 being a common upper bound. |
| 998 characters | RFC 5322 absolute maximum | The hard limit an SMTP message line must observe; everything past this must be encoded. |
All four small presets are one click in the formatter, and any other width from 8 to 500 can be typed directly, so the presets are starting points rather than the only options. The official Pro Git book section on contributing to a project and the POSIX specification of the fold utility are the two primary references behind those numbers.
How to Format Wrap Text with a Line-Length Formatter
The whole workflow takes three actions once the text is in hand:
- Paste the text and pick a width. Use 72 for email replies and commit messages, 80 for terminal output and classic code comments, 100 or 120 for modern code, or type any number from 8 to 500 if your destination has its own rule.
- Choose soft wrap or hard wrap, and decide on reflow and indentation. Soft wrap breaks at the last space that fits and never cuts a word; hard wrap cuts at the exact column for files that must observe a strict limit. Reflow joins existing line breaks inside a paragraph before re-wrapping, so text that is already wrapped at the wrong width comes out clean. Indentation handling is on by default and preserves leading spaces or quote prefixes on every continuation line.
- Read the stats and copy the result. The output panel reports lines in, lines out, the longest output line, and the count of any overlong words that were left intact under soft wrap. None of those numbers exceed the limit without your seeing them in the report.
For example, take this commit body paragraph that someone wrote as one long line in their editor:
This commit adds the new pagination helper to the user API. It supports both offset and cursor modes and falls back to offset mode when the cursor token is missing or has expired. Tests cover the empty-result case, the single-page case, and the multi-page case where the cursor advances past the dataset boundary.
Pasting that into the formatter at width 72 with reflow on turns it into lines no longer than 72 characters, broken at the last fitting space, with the paragraph kept as a single paragraph. The same paragraph re-wrapped at width 100 produces visibly longer lines and demonstrates that the column count, not the words, is what changes.
Soft Wrap Versus Hard Wrap: When to Use Each
Soft wrap is the right choice for anything a human will read as prose: emails, commit messages, man pages, READMEs, blog drafts. It treats the wrap as a presentation decision and never carves through a word. If a single word is longer than the chosen width — a long URL, a long identifier, a long hash — soft wrap leaves that word alone on its own line rather than splitting it, and the result panel reports how many such words were left intact so the limit is never silently exceeded. Soft wrapping is also idempotent: running the output through the formatter again at the same width changes nothing, which is useful in pipelines where the wrapped text may be wrapped again.
Hard wrap is the right choice for output that a fixed-width tool will consume: a banner for a 7-segment display, a file that another program reads line by line at a known column, a log line that has to fit inside a status bar, an S-record or a structured record where the column position is part of the format. Hard wrap cuts at the exact column and will not split a Unicode surrogate pair, so an emoji is never cut in half. The width is counted in Unicode code points, and the formatter states its one boundary plainly: East Asian full-width characters count as one code point, and the actual double-width rendering that a terminal applies on screen is not simulated.
Re-wrapping Existing Text Without Ruining Structure
The text you need to format is rarely a single long line. More often it is a paragraph that was already wrapped at 60 or 65 characters, or a code comment that was wrapped at 80 when the file moved to 100-column style, or an email reply that was wrapped at one width and then quoted at another. The reflow option is what makes those cases work: with reflow on, the formatter joins the existing breaks inside each paragraph first and then re-wraps at the new width, so old 60-column text comes out at 100 cleanly. With reflow off, every existing line is wrapped on its own, which is what you want when the line breaks are themselves meaningful — for example, in a poem, in a config file where each line is a record, or in a table that has been flattened to text.
Structure is preserved through all of this. Blank lines stay blank lines. Each paragraph wraps on its own, so a hard break between paragraphs does not turn into a soft break inside a paragraph. Indentation is subtracted from the effective wrap width, so a paragraph that starts with four spaces keeps those four spaces on every continuation line and stays aligned instead of drifting right as it grows. The same rule applies to quoted-email prefixes: angle-bracket prefixes count as indentation, so a reply keeps its quoting structure line by line even after re-wrapping at a new width.
For input size, the formatter caps text at one million characters and runs in a single linear pass, so it returns instantly even at that ceiling. Everything runs in the browser: nothing is uploaded, stored, or attached to an account, which makes it safe for code, draft emails and unpublished drafts.
Matching the Wrap Width to the Destination
Choosing the right width is mostly a question of where the text is going next. For Git commit bodies, 72 is the working number because Git's own contributing guide recommends it and because commits are routinely indented in git log output, in pull-request review interfaces, and in tools like git rebase -i. For emails, 72 is again the right answer because mailing-list replies stack quote prefixes and 72 plus several "> " levels still stays inside the 78-character RFC 5322 recommendation. For code comments and source code, 80 is the conservative pick that satisfies every legacy style guide, and 100 is the modern alternative that many current style guides allow. For READMEs and man-page-style documents that will be read both in a terminal and on a website, 72 or 80 keeps the prose tight enough to read comfortably in either place.
After the wrap, the next step is often to add line numbers for review or documentation — in which case the Add Line Numbers to Text guide shows how to number the wrapped output from a chosen starting value. For the opposite direction, when a paste has arrived with hard breaks you no longer want, the Word Wrap / Line Length Formatter with reflow off handles each existing line on its own.