Online Tool Store
Word Wrap Tool
Wrap text to any character width with greedy or balanced line breaking, and unwrap already-wrapped text so it can be re-wrapped cleanly. Scores both algorithms on your own text, and subtracts any line prefix from the width. Runs in your browser.
🔒 This tool runs entirely in your browser. Your files are never uploaded to a server.
Wrapped in this page; nothing is uploaded. Widths are counted in characters, which is what a fixed-width context — a terminal, a commit message, a plain-text email — actually cares about. For proportional text on a web page, let CSS wrap it instead; hard line breaks in HTML fight the reader's window size.
How to use it
- Paste your text and set a width — 72 for email, 80 for a terminal.
- If the text is already wrapped, run unwrap first, then wrap.
- Add a prefix such as
>to quote, or//to comment. - Check the comparison note — it tells you whether the balanced algorithm gains you anything here.
Two algorithms, honestly compared
Greedy wrapping fills each line as far as it will go. It is simple, it is what almost every tool does, and it produces a ragged edge that is sometimes lumpy — a very short line following a very full one. Balanced wrapping considers the whole paragraph and chooses breaks that even out the gaps.
The obvious question is whether that is worth having, so we measured it across 3,000 random paragraphs:
different output 21% of paragraphs
mean evenness gain 4.8% — modest
best case observed 407 → 275, about a third
extra lines used none in 20,000 paragraphs
So: usually it changes nothing, occasionally it helps a lot, and it does not appear to cost you a line. That is a fair reason to offer it and not a reason to claim it is better. The widget scores both on whatever you have pasted, and says plainly when the two are identical — which on ordinary prose at 72 characters they frequently are.
Why re-wrapping goes wrong
This is the mistake that makes people distrust wrapping tools. Wrapping inserts line breaks; it does not remove existing ones. Take text already wrapped at 80 columns, wrap it at 60, and every original break survives — so you get an alternating pattern of nearly-full and nearly-empty lines that looks far worse than either width alone.
The fix is to unwrap first. That joins each paragraph back into one long line, discarding the old breaks, after which wrapping to the new width does what you expected. Unwrap is a mode here for exactly that reason, and it respects paragraph breaks so your structure survives the round trip.
The prefix comes out of the width
If you wrap at 72 and add > to every line, the lines are
74 characters long — which defeats the point of choosing 72. So the prefix is subtracted from the available width here, and
indentation is treated the same way. The number you set is the width of the finished line, including whatever is in front of
it.
This is also why the email convention is 72 rather than 80: it leaves room for two levels of quoting before a reply spills past 80 columns in someone else's mail client.
When not to use this at all
Do not hard-wrap text destined for a web page or any proportional-font context. Character counts assume every character is the same width, which is only true in a monospaced setting. Worse, baked-in line breaks override the reader's window size, font preference and zoom, and look broken on a phone. CSS already wraps text correctly for the space available.
Where character wrapping genuinely belongs: plain-text email, git commit messages, code comments, terminal output, fixed-width reports and configuration files. In all of those, nothing downstream is going to reflow the text, so the width has to be decided when you write it.
FAQ
What is the difference between greedy and balanced?
Greedy puts as many words on each line as will fit, which is what fmt, most editors and nearly every online wrapper do. Balanced looks at the paragraph as a whole and picks the breaks that make the ragged right edge most even. We measured both across 3,000 random paragraphs: they produce different output about 21% of the time, and balanced improves average evenness by only 4.8%. So the widget shows you both scores for your actual text rather than claiming one is always better.
Then when is balanced actually worth it?
When your paragraph has awkwardly varied word lengths at a narrow width. In the worst case we found across those 3,000 paragraphs, balanced took the raggedness score from 407 to 275 — about a third more even, which is plainly visible. On ordinary prose at 72 characters the two often agree exactly, and the widget will tell you when that is the case rather than implying you gained something.
Does balanced ever cost me an extra line?
Not in 20,000 random paragraphs we tested — it never used more lines than greedy. That is a measurement rather than a proof, but it means you can reasonably treat evenness as free. The reason is that the last line is excluded from the cost, so the algorithm has no incentive to pad the paragraph out.
Why must I unwrap before re-wrapping?
Because wrapping only adds breaks; it does not remove the ones already there. Text wrapped at 80 and then wrapped at 60 keeps its original breaks and you get a mess of short lines. Unwrap first to join each paragraph back into a single line, then wrap to the width you want. This is the most common reason a wrapping tool appears to produce nonsense.
Why 72 rather than 80?
Convention, and a practical one for email: wrapping at 72 leaves room for a couple of levels of quote markers before the text exceeds 80 columns in someone else's reply. For terminal output 80 is the traditional width. For git, the widely followed convention is a subject line around 50 characters and a body wrapped at 72. None of these are rules, but they are what other people's tools assume.
Should I hard-wrap text for a web page?
No. Hard line breaks fight the reader's window, their font size and their zoom level, and they break badly on a phone. Let CSS wrap proportional text. Character-counted wrapping is for genuinely fixed-width contexts — terminals, plain-text email, commit messages, code comments — where nothing is going to reflow it for you.
How we compare
| Feature | Online Tool Store | fmt or par | Other online wrappers |
|---|---|---|---|
| Text never leaves your device | ✓ | ✓ | ✗ |
| Balanced as well as greedy wrapping | ✓ | par only | ✗ |
| Scores the two on your own text | ✓ | ✗ | ✗ |
| Unwrap for safe re-wrapping | ✓ | ✓ | Rarely |
| Prefix subtracted from the width | ✓ | ✓ | ✗ |
| Works on a whole directory of files | ✗ | ✓ | ✗ |
| Understands Markdown or code structure | ✗ | Partly | ✗ |
Good for one block of text you want wrapped correctly, with the evidence to decide which algorithm to use. It treats the input as plain prose — it does not know a Markdown list from a paragraph or a code block from a comment, so wrap those by hand or with a formatter that understands the syntax.