Text Wrap vs. Word Wrap: Hard-Wrapping Text to a Column Width Without Breaking Words

There are two kinds of line wrapping, and they are not the same thing. Soft wrap is what your editor draws on the screen: the line looks like it stops at the window edge, but underneath it is still one long line. The moment that text lands somewhere narrower, a commit message body, an email quote, a code comment under a strict linter, it reflows into a mess. Hard wrap is the opposite. It inserts a real newline character at the column you pick, so the wrapping travels with the text wherever you paste it.

This post is about doing hard wrapping correctly: choosing a width, breaking on word boundaries so you never split a word mid-letter, and keeping your paragraphs separate. The Text Wrap tool does all of this in the browser, and I will walk through the cases where it actually matters.

The one rule that makes wrapping readable

Here is the rule, and it is the whole game: wrap at a width on word boundaries, and never break a word mid-character unless you explicitly ask for it.

Word-boundary wrapping works like this. You set a column width, say 80. The wrapper fills a line word by word. Before it adds the next word, it checks: would this word push the line past column 80? If yes, the word does not go on this line. It starts a fresh line, whole. The current line ends a few characters short of 80, and that is fine, ragged-right is what readable prose looks like. A word that is longer than the entire width (a 90-character URL at width 80) simply overflows on its own line rather than getting chopped, because in word mode the word is sacred.

The alternative is force-cut mode, which breaks anywhere. A 120-character URL at width 40 becomes three clean 40-character chunks. You want this when a hard column cap matters more than keeping words intact, fixed-width data fields, terminal banners, legacy forms. For anything a human reads, word-boundary mode is the right default.

A worked example: wrapping to 40 columns

Let me show the actual transformation. Here is one long line, 118 characters, with no newlines in it:

The wrapper fills each line word by word and starts a new line whenever the next word would exceed the column limit.

Run that through word-boundary wrapping at a width of 40 columns and you get:

The wrapper fills each line word by word
and starts a new line whenever the next
word would exceed the column limit.

Count the characters in each output line and none of them exceed 40. Line one stops at 40 exactly ("word by word" ends right at the boundary). Line two stops at 39, because adding the next word, "word", would have hit 44. So "word" jumps to line three. Notice what did not happen: no word got cut in half. "whenever" was never split into "whenev" and "er". That is the word boundary doing its job. Switch the same input to force-cut and you would instead see lines of exactly 40 characters each, with words sliced wherever the count runs out.

Where hard wrapping earns its keep

Three places in a developer's day where this is not optional.

Commit messages at 72 columns. Git's own convention wraps the body of a commit message at 72 characters. The reason is mechanical: git log indents the body by four spaces, and 72 plus that indent still fits an 80-column terminal without wrapping awkwardly. If you write a paragraph-long commit body in an editor that soft-wraps, it goes in as one giant line, and every git log viewer reflows it differently. Wrap it to 72 first and the body reads identically everywhere.

Plain-text email. Email settled on 72 columns for a related reason: each level of quoting prepends a > marker, and 72 plus a few quote levels still fits the classic 80-column width. If you send an unwrapped body, the first person to reply gets ragged, runaway lines that no longer line up. Wrapping at 72 before you send keeps the thread tidy three replies deep.

Code comments under a linter. Plenty of teams cap comment lines at 80. Paste a long explanation above a function and the linter lights up. Wrapping to 80 with a comment prefix solves it: every output line comes out already prefixed with // and already within budget, ready to drop in.

Prefixes count against the width

This is the detail people get wrong. If you wrap to 80 and then manually add a > quote marker to every line, your lines are now 82 characters, over budget. The prefix has to be part of the calculation.

Set the prefix inside the tool, a quote > , a comment // , a list bullet, and it is subtracted from the column budget before wrapping. At width 80 with a 2-character prefix, each line holds 78 characters of text plus the marker, and the finished line ends at exactly 80. That is how plain-text email and Markdown quote a passage, and it is the only way to get a quoted block where every line genuinely fits the width.

Keep your paragraphs, don't flatten them

A good wrapper treats blank lines as paragraph breaks. Each block of text between blank lines is wrapped on its own, and the blank line between blocks survives, so a two-paragraph note stays two paragraphs instead of collapsing into one wall of text. That is the default behavior you want for prose.

There is an honest caveat I hit constantly, and it is worth stating plainly. The first time I tried to wrap a block of text that had been pasted out of a soft-wrapping editor, I got nonsense, the output had short, weirdly-staggered lines. The cause: the input already had a newline after every visual line, so the wrapper was faithfully re-wrapping a pile of pre-broken short lines instead of flowing paragraphs. The fix is to un-wrap first. Join the lines back into full paragraphs with a tool like Remove Line Breaks, then hard-wrap to the width you actually want. Strip, then wrap, in that order, and the result comes out clean every time.

Picking a width and shipping it

So: 72 for commit messages and email bodies, 80 for code comments and most documentation, and whatever exact value a fixed-width field demands. Choose word-boundary mode for anything a person reads, force-cut only when the column cap is non-negotiable and you would rather slice a token than overflow. Add the prefix inside the tool so it is counted, and leave paragraph-keeping on for prose.

Everything runs as plain JavaScript in your tab, nothing is uploaded, and you get one-click copy plus a shareable link. Paste a paragraph, set the width, read the result, and the real newlines you get back will hold their shape in every editor, mail client, and git log that ever touches them. Try it on your next overlong commit body and watch it wrap clean.

---

Made by Toolora · Updated 2026-06-13