I'm wondering if word wrapping should be applied in text emails? And what about HTML emails? If so, what character would you normally wrap at?
-
1Good answer is here: http://stackoverflow.com/questions/2696433/is-it-necessary-to-wrap-long-lines-when-sending-emails/2696542#2696542 – Marco Demaio Jun 08 '11 at 15:24
-
See also http://stackoverflow.com/questions/4297574/do-i-need-to-wrap-email-messages-longer-than-72-characters-in-a-line/4297689 – Chris J Sep 08 '16 at 07:28
9 Answers
RFC 2646 says:
The Text/Plain media type is the lowest common denominator of Internet email, with lines of no more than 997 characters (by convention usually no more than 80)
Another popular standard is to wrap at 72 characters. This dates back to many console applications (like EDIT and many BBS interfaces) that displayed text within an ASCII "window" including a border and scrollbar, allowing slightly less than 80 characters to be displayed.

- 7,489
- 31
- 48
-
Agreed. I always wrap at 80, and if that would break a word, I'd wrap at less than 80, wherever the first space or line break is prior to that eightieth character. – hmcclungiii Jan 19 '09 at 21:48
It is common to wrap lines at 72 (80 is also common but that means that it will go over 80 when quoted) to handle at least one or two levels of quotation. There is the "text/flowed" MIME type which means that the client will wrap text itself at window's boundaries but not that many clients support it. Just setup your editor to wrap at 72 and you will be safe and readable by the most people.
EDIT: the exact type is text/plain
with the addition of format=flowed
like this:
Content-Type: text/plain; format=flowed
See rfc2646 for explanations.
HTML mail should be avoided IMNSHO, not everybody reads mail in a browser or have HTML-enabled mail clients. Most reasons to use HTML (enriching mail with underline, bold and such) can be emulated. HTML doesn't need to be wrapped as the client will adapt to the window size.
An alternative to HTML is the "text/enriched" MIME type which gives you most of the advantages of HTML mails w/o the hassle but again, may not be supported everywhere.
See here for text/enriched.
Google says Results 1 - 10 of about ...
3,160 for +word +wrap +email +"80 characters"
2,820 for +word +wrap +email +"50 characters"
1,790 for +word +wrap +email +"60 characters"
1,720 for +word +wrap +email +"70 characters"
1,540 for +word +wrap +email +"100 characters"
1,250 for +word +wrap +email +"65 characters"
1,120 for +word +wrap +email +"40 characters"
962 for +word +wrap +email +"75 characters"
836 for +word +wrap +email +"72 characters"

- 7,489
- 31
- 48
-
2Google can only tell you where is the crowd going... not if it's going in the right direction :-) – siukurnin Jan 19 '09 at 22:10
-
3Sure, but the gist of this question was mostly where the crowd is going :) – Sparr Jan 20 '09 at 20:06
RFC 5322
https://www.rfc-editor.org/rfc/rfc5322#section-2.1.1
2.1.1. Line Length Limits
There are two limits that this specification places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
The 998 character limit is due to limitations in many implementations that send, receive, or store IMF messages which simply cannot handle more than 998 characters on a line. Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake. However, there are so many implementations that (in compliance with the transport requirements of [RFC5321]) do not accept messages containing more than 1000 characters including the CR and LF per line, it is important for implementations not to create such messages.
The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification (and that of [RFC5321] if they actually cause information to be lost). Again, even though this limitation is put on messages, it is incumbent upon implementations that display messages to handle an arbitrarily large number of characters in a line (certainly at least up to the 998 character limit) for the sake of robustness.
See also: RFC2045, RFC2046, RFC2047, RFC2049, RFC4289 & RFC6838 for MIME specs.
It's fun reading RFCs. You know you love it :-)

- 4,217
- 2
- 33
- 41
I often find myself starting e-mail replies with:
[Format recovered--see http://www.lemis.com/grog/email/email-format.php]
which I got from Greg Lehey. Part of that page says:
Clearly, there must be some way of specifying that the message text should not be wrapped. That's text/plain. There are special MIME attachment types which allow wrapping, although I still think that this is a bad idea. If you specify that your message may be wrapped, you're making an assumption about what the receiver's screen looks like. Even if you're right some of the time, you can't be right all of the time. For example, one person may have a screen 200 characters wide in order to be able to display long log file entries, but he won't want to see his text that long.

- 7,729
- 4
- 49
- 65
-
@JamesDaily thanks, ~2011 the old link started redirecting to a *.php link and sometime in the last six months that stopped. For future reference if the link above stops here is an [archive.org link](https://web.archive.org/web/20100402074443/http://www.lemis.com/email/email-format.html). – Dave C Feb 16 '17 at 15:41
A good mail API like JavaMail will do this for you. Ideally, you would not have to think about this issue explicitly.

- 15,703
- 8
- 51
- 58
-
Agreed, and on all newer sites I do use a library. On this site unfortunately, it's so old I did not and it would be a paid to add one. – Darryl Hein Jan 20 '09 at 21:52
Generally you should wrap at 80, or a little less to allow dim clients to quote without wrapping.

- 52,368
- 9
- 94
- 137
Wrap at the first whitespace character before the 72nd position, or at the 72nd position if there isn't one. In Eudora when I used to use it, the convention was to leave a space at the end of the line indicating that it was wrapped, so it would signal the receiving client to re-flow the paragraph wherever it needed based on the width of the client's window. I'm not sure that this is the case in current email clients.

- 8,614
- 3
- 33
- 47
-
I think the trailing character (be it a space, hyphen, or other wrap-breakable punctuation) should always be left. – Sparr Jan 19 '09 at 21:58
Didn't use linewrap, until I had switched to mutt/xterm (never looking back).

- 50,694
- 11
- 78
- 122

- 50,406
- 14
- 85
- 110