Removing word wrap online means reformatting text that has already been broken at one column width to a different column width without losing any words or paragraph structure. The Word Wrap / Line Length Formatter handles that operation in a single browser pass: paste text that is already wrapped, pick a target line length such as 72 for email and commit messages, 80 for the classic terminal width, or any custom value from 8 to 500 characters, and the same words come back re-laid at the new limit. The tool joins the existing line breaks inside each paragraph before re-wrapping, so a 60-column PDF paste becomes a clean 72-column email body, a 72-column commit message becomes an 80-column reply, and an 80-column code comment becomes whatever the project's style guide actually asks for. Blank lines stay as paragraph breaks and each paragraph wraps independently. Any leading indentation, including quoted-email '>' prefixes, is preserved on every continuation line and counted against the wrap budget so indented blocks stay aligned. Overlong words such as long URLs are never cut; they stand alone on their own line and the output reports how many such words were left intact, which means no line silently exceeds your chosen width. Soft wrapping at the same width is idempotent, so running the output through again at the same width changes nothing — a useful property when the wrapped result is fed into a longer text pipeline. Everything runs locally; nothing is uploaded, stored, or attached to an account.
What 'Removing Word Wrap' Means in Practice
Almost every paste of plain text carries some kind of wrap: a 60-column PDF, a 72-column email reply chain, an 80-column terminal capture, or a 100-column source-code comment. When that paste lands somewhere that expects a different width — a Git commit body, a mailing-list reply, a man page, a README, a code review comment — the existing breaks need to be replaced with new ones at the target limit. Stripping an existing word wrap is exactly the same operation that the standard Unix POSIX fold utility has performed for decades: take text already broken at one column and re-lay the same words at another column, without losing any characters or rearranging the order of words.
The Word Wrap / Line Length Formatter is built for exactly that operation. Its reflow option is the switch that joins existing line breaks inside each paragraph first, then re-wraps the joined paragraph at the new width. With reflow on (the default), a 60-column PDF paste becomes a clean 72-column email, a 72-column commit body becomes an 80-column reply, and a 100-column source comment becomes whatever the project style guide actually asks for. With reflow off, the tool wraps each existing line on its own — which is the right mode when line breaks are part of the data, such as poetry, log extracts, or ASCII art that must not be re-laid.
The operation runs in a single linear pass over the text, so a one-million-character input wraps and returns the result without spinning the CPU. Nothing is uploaded, attached to an account, or stored — the page processes everything in the browser tab.
How to Re-Wrap Already Wrapped Text at a New Width
- Open the Word Wrap / Line Length Formatter in a new browser tab; it runs locally and does not upload the text.
- Paste the already-wrapped text into the input field. PDF copies, terminal captures, email replies, and commit-message drafts all work the same way.
- Pick a width: click 72 for emails and commit messages, 80 for the classic terminal width that code style guides still reference, 100 for modern prose, or 120 for wide documentation; you can also type any custom width from 8 to 500 characters.
- Leave the reflow option on so the tool first joins the existing line breaks inside each paragraph before re-wrapping. Switch reflow off only when each existing line carries meaning of its own, such as in poetry or a code block.
- Choose soft wrap to break at the last fitting space, or hard wrap to cut at the exact column when a downstream system genuinely requires every line to be under the limit.
- Check the longest-line stat to confirm the output matches the target, then read the lines-in / lines-out counters and the overlong-word count.
- Copy the wrapped result and paste it into the destination: a commit message, an email reply, a code comment, or a plain-text document.
If the tool reports overlong words left intact, look at the input — those are usually URLs, commit hashes, file paths, or single identifiers that genuinely exceed the limit. Soft wrap will not cut them, and the tool tells you how many such words were preserved so nothing silently breaks the chosen line-length rule. The same happens with quoted lines from a previous email: every level of '>' or '> >' prefix stays attached to the line that contains it, so the new wrap never accidentally drops a quoting level.
Preset Widths and When to Use Them
| Preset | Conventional use | Why the number |
|---|---|---|
| 72 | Email body lines and Git commit message body lines | RFC 5322 advises message lines to stay within 78 characters; wrapping body text at 72 leaves room for one or two levels of quote prefixes to be added later without forcing a re-wrap. |
| 80 | Classic terminal width, source-code style guides, man-page sections | Code style guides still reference 80 columns because the traditional fixed-width terminal display was 80 characters wide, and the convention carried into source-code style rules. |
| 100 | Modern prose, blog drafts, READMEs, longer source-code lines | A wider cap that still fits comfortably inside most terminals at default font sizes without horizontal scrolling. |
| 120 | Long-form documentation, wide code style guides, notebook prose | The widest preset, suited to displays wider than a 1970s terminal but narrower than an A4 page in monospace. |
For commit-message bodies specifically, the Git project's own contributing documentation recommends wrapping body text at a fixed column so the message survives indented display in logs without breaking layout. The 72 preset matches that recommendation directly. If none of the presets fit, type any width from 8 to 500 directly into the width field and the tool wraps to that limit on the next pass.
Soft Wrap vs Hard Wrap: Picking the Right Mode
Soft wrap is the default and is what almost every reader of plain text wants. It breaks at the last space that still fits inside the limit, so every line ends on a word boundary and nothing inside the line is cut. A word longer than the limit — a long URL, a file path with no spaces, a single unbroken identifier — stays whole on its own line, and the result reports how many such words were left intact so nothing silently exceeds the chosen width. This is the safer mode for any human-readable destination: emails, commit messages, README files, mailing-list posts, and code comments.
Hard wrap is the strict mode: it cuts at the exact column you picked, even inside a word, because some downstream systems genuinely require every line under a hard limit (older mail relays, fixed-record databases, certain log shippers). The tool will never split an emoji or any other character that occupies two Unicode code units, which is a correctness detail that naive column-cutters routinely get wrong. If the input is plain English at 72 chars per line, hard wrap and soft wrap usually produce identical output; they diverge only when a single token exceeds the width.
Soft wrapping at the same width is idempotent: running the output through the tool again at the same width changes nothing. That makes the operation safe inside a longer pipeline — re-paste the result, re-process it, or feed it into a different formatter without accidentally re-cutting already-cut lines. The longest-line stat lets you verify the width actually matches the target, which catches the common mistake of pasting the input twice and getting the same number reported in both columns.
What the Tool Preserves Across the Wrap
Removing an existing word wrap is not the same as collapsing every line break. The tool keeps blank lines as paragraph breaks and wraps each paragraph independently, so a pasted document keeps its paragraph structure instead of becoming one wall of text. Each paragraph starts fresh: the existing line breaks inside it are joined during reflow, the joined text is laid out at the new width, and the next blank line starts a new paragraph.
Indentation is preserved and accounted for. A paragraph that starts with four spaces keeps those four spaces on every continuation line, and the effective wrap width subtracts them. The arithmetic: at a target width of 72 with 4 spaces of indentation, the effective wrap width equals 72 − 4 = 68 characters per continuation line. Quoted-email prefixes made of angle brackets are treated as the same kind of indentation, so a reply with '> >' prefixes stays aligned no matter what level is added. A 100-column prose paragraph with no indentation, by contrast, gets the full 100 characters on every line.
Width is measured in Unicode code points, not bytes, so accented letters, Cyrillic, Greek, Hebrew, Arabic, and emoji each count as one unit. The page states its one scope boundary plainly: East Asian full-width characters count as one, terminal double-width rendering is not simulated. The result also reports lines in, lines out, and the longest output line, so there is a number to check against whatever line-length rule is being satisfied. The Word Wrap / Line Length Formatter handles long code comments, mailing-list replies, commit-message bodies, and man-page sections in the same pass, with a one-million-character input cap that is well above any realistic email or commit body.
If you're weighing options, Wrap Every Line in Quotes for JSON, SQL, and CSV covers this in detail.
If you're weighing options, Convert a Google Sheets Column to a Comma-Separated List covers this in detail.