Word Wrapper
Wrap text to any column width — 60, 72, 80, 100, or custom. Hard breaks for emails and terminals, soft wrap for display.
Column width
Hard break
Cut at exactly 80 chars; soft wrap respects word boundaries.
Use this with
Related cleanup & transforms tools
Text Formatting Guide
Column width standards and why they matter for readability
Text wrapping controls the maximum line length of your content. Proper line length is one of typography's most overlooked readability factors — lines that are too long cause readers to lose their place, while lines too short create jarring rhythm. Different contexts have different standards.
72 characters: the email standard
RFC 2822 (the email specification) recommends 78 characters maximum per line, with 72 being the practical standard. Email clients that do not reflow text will display longer lines truncated or with awkward wrapping. Plain text email newsletters, transactional emails, and developer notifications should all wrap at 72.
80 characters: the terminal and code standard
The 80-column limit comes from 1970s terminal screens. It remains the most common coding style guide requirement — used by PEP 8 (Python), Google Style Guide, and most open-source projects. Code comments, commit messages, README files, and changelog entries should all wrap at 80.
60 characters: optimal prose readability
Typography research consistently shows 55-75 characters per line as the optimal range for prose readability. At 60 chars, the eye completes each line without fatigue. This is the standard for printed books, quality long-form web content, and newsletter body text. Wider is not always better.
Hard vs soft wrapping
Hard wrapping inserts actual newline characters (\n) at the specified width — the text stays wrapped regardless of screen size. Soft wrapping adds a display-only wrap — the underlying text has no breaks. Use hard wrapping for plain text files, email, and terminal output. Use soft for HTML/web content.
Markdown and documentation
GitHub Markdown files, README docs, and documentation in version control should be hard-wrapped at 80 characters so they read cleanly in terminal viewers, raw GitHub previews, and text editors without line wrap. Pull request descriptions also benefit from 80-column wrapping.
Git commit messages
Git convention: subject line under 50 characters, body wrapped at 72 characters. Commit messages that exceed these limits are truncated in git log, GitHub PR views, and CI log output. Tools like git log --oneline and GitHub's commit list view all truncate at 72 chars.
Pro Tips
Many email clients (especially corporate Outlook setups and legacy clients) display plain-text emails without reflowing lines. A 200-character line becomes a horizontal scroll nightmare. Wrap at 72 before sending any plain-text email — it is the one formatting rule that applies universally.
Set up your git editor to hard-wrap at 80 automatically: in vim, add "set textwidth=72" to .vimrc. In VS Code, the GitLens extension can enforce this. Well-formatted commit messages are a signal of engineering maturity and make git log output readable for the entire team.
Web content does not need manual wrapping (the browser handles it), but check your actual rendered line length at your most common reading width. Use a character-per-line counter at 1200px viewport. If lines exceed 90 characters at desktop, increase font size or reduce content column width.
Frequently Asked Questions
- What is the standard column width for plain text?
- The most widely accepted standard is 80 characters — derived from the original 80-column terminal. For email, 72 characters is the recommended limit per RFC 2822. For prose (articles, books), 60-75 characters per line is the typographic optimum for readability. Use 80 as your default and adjust based on context.
- What is the difference between hard wrap and soft wrap?
- Hard wrap inserts actual newline characters at the specified column width — the line break is physically embedded in the text file. Soft wrap changes how the text is displayed without altering the underlying content. Use hard wrap for: plain text files, emails, terminal output, code comments, and git commit messages. Use soft wrap for: HTML content, word processor documents, and anything that will be reflowed by a renderer.
- Why does git recommend wrapping commit messages at 72 characters?
- Git tools display the commit body with a 4-character indent in many views, bringing the effective display width to 76 characters in an 80-column terminal. Wrapping at 72 ensures the body reads cleanly in all standard git interfaces: terminal git log, GitHub web UI, GitLab, and email patches. The subject line should be under 50 characters for clean one-line log output.
- Does line length affect SEO?
- Indirectly. Web browsers reflow HTML text so manual line length does not affect how text renders on screen. However, very long line lengths in your actual HTML source (unminified) can affect HTML file size and parsing speed. More importantly, optimal line length improves readability, which reduces bounce rate — a real engagement signal that correlates with rankings.