About

Fixed-width text formatting is a requirement in commit messages (Git enforces 72 characters), code comments, plain-text emails (RFC 2822 recommends 78 characters), and terminal output. Manual line-breaking is error-prone: one misplaced break corrupts a paragraph when the text is later reflowed. This tool performs greedy line-filling against a configurable width W, optionally prepending each output line with a fixed string (e.g. // or # ). The prefix length is subtracted from W before wrapping, so content never exceeds the column limit. Paragraph boundaries, denoted by consecutive blank lines, are detected and preserved in both directions.

The unwrap (fixed → fluid) operation reverses the process: it strips the prefix from each line, joins lines within the same paragraph block into a single flowing string, and restores double-newline paragraph separators. Note: unwrapping assumes lines were originally wrapped by this algorithm or a compatible greedy wrapper. Text with intentional short lines (poetry, ASCII art) will be collapsed. Words longer than W − len(prefix) are placed on their own line without breaking, so the output may exceed the column limit for those tokens.

Formulas

The wrap algorithm uses greedy line-filling. Given a maximum line width W and a prefix string P, the effective content width per line is:

W_eff = W − len(P)

For each paragraph (block of text separated by double newlines), words w₁, w₂, …, w_n are placed sequentially. A word w_i fits on the current line if:

currentLen + len(w_i) + 1 ≤ W_eff

where the 1 accounts for the separating space (omitted for the first word on a line). If the word does not fit, the current line is flushed as P + lineContent, and a new line begins with w_i. If a single word exceeds W_eff, it occupies its own line (the line will exceed W; no mid-word hyphenation is applied).

The unwrap operation reverses this. Consecutive non-blank lines form a paragraph block. For each line, the prefix P is stripped from the start (if present). The remaining content is joined with single spaces. Paragraph blocks are separated by double newlines in the output.

Reference Data

Context	Standard Width	Common Prefix	Source / Authority
Git commit body	72 chars	(none)	Git project guidelines
Python docstrings (PEP 257)	72 chars	(4 spaces)	PEP 257
Linux kernel comments	80 chars	*	kernel coding style
RFC 2822 email	78 chars	>	IETF RFC 2822 §2.1.1
USENET / plain text	80 chars	(none)	Historical convention
Java / C / C++ block comment	80 - 120 chars	* or //	Google style guides
Python PEP 8	79 chars	#	PEP 8
Ruby style guide	80 chars	#	rubystyle.guide
Rust (rustfmt default)	100 chars	//	rustfmt.toml default
Go (gofmt)	No hard limit	//	Effective Go
Fortran fixed-form	72 chars	C	Fortran 77 standard
COBOL Area A+B	72 chars	(cols 1-6 reserved)	COBOL-85 standard
Terminal (standard)	80 chars	(none)	VT100 / ANSI
Terminal (wide)	120 chars	(none)	Modern default
LaTeX body text	80 chars	%	Convention
Markdown prose	80 chars	(none)	markdownlint MD013
SQL line comments	80 - 120 chars	--	Convention
Shell scripts	80 chars	#	Google shell style guide

Frequently Asked Questions

The word is placed on its own line without breaking. The resulting line will exceed the column limit. Mid-word hyphenation is not applied because it would corrupt code identifiers, URLs, and technical tokens. If you need hyphenation, pre-process the text before wrapping.

A paragraph boundary is any sequence of two or more consecutive newline characters (with optional whitespace between them). During wrapping, the input is split on this pattern, each paragraph is wrapped independently, and the output paragraphs are joined with exactly two newline characters. During unwrapping, blank lines are detected the same way to re-establish paragraph blocks.

Yes. If you set width to 80 and prefix to "// " (3 characters), each line of content may use at most 77 characters. The prefix is prepended after wrapping, so the total output line length equals the configured width. If the prefix length is greater than or equal to the width, the tool will warn you and refuse to wrap.

Yes. Set the width to 72 and leave the prefix empty. Paste your commit body text into the input. The output will conform to the Git project guideline of 72 characters per line. The first (subject) line of a commit should be 50 characters or fewer and is not handled by paragraph wrapping - write it separately.

Unwrapping joins all consecutive non-blank lines with a space after stripping the prefix. If the original text contained intentional short lines (e.g., poetry, ASCII art, or tabular data), those lines will be collapsed into a single flowing paragraph. Only use unwrap on text that was previously hard-wrapped from prose.

Trailing whitespace is trimmed from every output line. This matches the behavior expected by most linters and version control systems, which flag trailing whitespace as an error.