Skip to content
ToolBoxGeniehome

Text Wrapper

Text Tools · Added

A text box wraps lines for display and leaves the string untouched. Several formats need the line breaks to be real characters — git commit bodies, plain-text email, code comments, fixed-width output — and this puts them in at whatever column you choose, breaking at spaces so no word is cut.

Direction

Blank lines separate paragraphs and are preserved either way.

Applied to the first line of each paragraph

Applied to every line after the first

How to use the text wrapper

  1. 1Paste your text and pick the column to wrap at.
  2. 2Add an indent if the text sits inside something — a comment block or a quoted reply.
  3. 3Check the longest-line figure; anything over the width is a single word that could not be broken.
  4. 4Switch to Unwrap to go the other way and join each paragraph back into one line.

Examples

A commit body

Input
A three-sentence paragraph, wrapped at 72
Result
Lines of at most 72 characters, so git log's four-space indent still fits inside 80

A word longer than the line

Input
A paragraph containing a 90-character URL, wrapped at 72
Result
One line overflows, and the tool says so rather than splitting the URL

Switching on word breaking splits it; leaving it off keeps the URL usable.

About the text wrapper

Soft and hard wrapping are different things

A textarea, a chat window and a word processor all wrap lines for display without touching the underlying text: resize the window and the wrapping changes. That is soft wrapping, and it is the right behaviour for anything that will be read on a screen of unknown width.

Hard wrapping puts newline characters into the data. Once done, it does not adapt — text hard-wrapped at 80 and then read in a 40-column window wraps twice and looks ragged. That is the cost, and it buys predictability: the output looks the same everywhere, which is why formats older than resizable windows still ask for it.

Where a hard wrap is still expected

Git commit messages, by strong convention: a short subject, a blank line, then a body wrapped at 72. Plain-text email, where RFC 5322 sets a hard limit at 998 characters and convention sets a much shorter one. Code comments, wherever the project has a column limit. Fixed-width reports and anything destined for a terminal.

The common thread is that the reader's display width is unknown but bounded, and the writer would rather choose the line breaks than let something else choose them badly.

Frequently asked questions

Why 72 columns rather than 80?
Because both git and email add something to the left. Git log indents a commit body by four spaces, and each level of email quoting adds a marker, so text wrapped at 72 survives a few rounds of either and still fits an 80-column terminal. Wrapping at exactly 80 means the first person to quote you breaks the formatting.
What happens to a word longer than the width?
By default the line overflows and the result tells you how many lines did. Wrapping breaks at whitespace, and a 90-character URL contains none — there is nowhere to break it. You can switch on word breaking, but for a URL that is usually the wrong trade, because a URL split across two lines stops being one.
Is unwrapping the exact opposite of wrapping?
No, and it cannot be. Hard wrapping throws away the record of which line breaks were deliberate, so afterwards a break the wrapper inserted is indistinguishable from one the writer meant. Unwrapping joins every line within a paragraph. Paragraph boundaries survive because they are blank lines rather than single breaks.
Does it preserve the paragraph structure?
Yes. Blank lines mark paragraph boundaries and are kept in both directions, so a document keeps its shape. A line holding only spaces counts as blank, because otherwise two paragraphs separated by one would silently merge into a single block.

Related tools