Somewhere in the folklore of email, a rule is repeated with the confidence of scripture: lines in email should be 78 characters, because RFC 822 said so. It is a tidy story. It has a date, a document number, and a number that sounds technical. It is also, on inspection, not quite right.
RFC 822, published August 13, 1982, is the standard that gave us the header syntax we still use — the From:, To:, Subject: fields, the folding rules, the address grammar. It is a foundational document. But if you read it looking for a line-length rule, you will not find one. The 78-character figure does not appear in RFC 822. It appears, instead, in RFC 2822, published in April 2001, and it is carried forward into RFC 5322, the current Internet Message Format specification, published in October 2008.
This matters for writers who care about format, because the difference between a rule and a recommendation is the difference between a constraint you must satisfy and a courtesy you choose to extend. The 78-character line is a courtesy. Knowing that changes how you use it.
What RFC 822 actually specifies
RFC 822 is a syntax document. It defines how a message is structured: header fields, a body, the separation between them. It specifies that a header field can be folded — split across multiple lines — by inserting a carriage return and line feed followed by at least one whitespace character wherever linear whitespace is permitted. The purpose of folding is to let long header fields, like a To: line with many recipients, be represented across several physical lines while remaining a single logical line.
What RFC 822 does not do is tell you how many characters a line may contain. It describes the grammar of messages, not their display. The document is explicit that it is not intended to dictate user interface characteristics: “This standard is NOT intended to dictate the internal formats used by sites, the specific message system features that they are expected to support, or any of the characteristics of user interface programs that create or read messages.” Line length, in RFC 822, is a display concern, and display is out of scope.
The 78-character rule that people attribute to RFC 822 is a later addition. It belongs to RFC 2822, which superseded RFC 822, and to RFC 5322, which superseded RFC 2822. The attribution is a case study in how a later document’s recommendation gets retroactively attached to an earlier, more famous standard. RFC 822 is the document people cite; RFC 2822 is the document that actually states the number.
The two limits: 998 and 78
RFC 2822, published in April 2001, is where the line-length rule enters the specification. Section 2.1.1, “Line Length Limits,” states: “There are two limits that this standard 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.”
RFC 5322, published in October 2008 and still the current Internet Message Format specification, carries the same two limits forward in identical language: “Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.”
The distinction between MUST and SHOULD is not decorative. In the terminology these documents use, MUST indicates an absolute requirement. SHOULD indicates a recommendation: there may exist valid reasons to ignore it, but the implications should be understood. The 998-character limit is a hard ceiling. The 78-character limit is a target.
The rationale for each is given in the specification itself. The 998-character limit exists because “many implementations that send, receive, or store IMF messages… simply cannot handle more than 998 characters on a line.” The 78-character recommendation exists “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.”
Note the direction of the accommodation. The 78-character recommendation is aimed at senders, asking them to be conservative so that receivers’ displays do not mangle the message. The specification is clear that this is a concession to imperfect implementations, not an ideal: it notes that such implementations are “non-conformant to the intent of this specification” and that “it is incumbent upon implementations that display messages to handle an arbitrarily large number of characters in a line.”
In other words, the spec would prefer that displays handle long lines gracefully. It recommends 78 because many do not.
Where the number comes from
The 78-character figure is not arbitrary, but neither is it derived from the protocol. It is a display-compatibility convention, and its history is the history of the screen.
RFC 3676, “The Text/Plain Format and DelSp Parameters,” published in February 2004, gives the clearest account of the reasoning. This document defines Format=Flowed, a mechanism for marking soft line breaks so that receivers can reflow text to fit their own displays. In describing how to generate flowed text, it states that lines “SHOULD be 78 characters or shorter, including any trailing white space and also including any space added as part of stuffing.” It then explains why:
“In addition to conformance to [MSG-FMT], there is a historical need that all lines, even when displayed by a non-flowed-aware program, will fit in a standard 79- or 80-column screen without having to be wrapped. The limit is 78, not 79 or 80, because while 79 or 80 fit on a line, the last column is often reserved for a line-wrap indicator.”
This is the terminal width that still shapes plain text. The 80-column screen — itself a descendant of the 80-column punched card — is the container that the 78-character line was designed to fit. The number is 78 rather than 80 because two columns are reserved: one for the wrap indicator, and one for the margin that keeps text from touching the edge.
RFC 3676 also notes that the number has never been stable. It suggests that paragraphs longer than 78 characters “could be wrapped using lines of 72 or fewer characters,” and observes that “it has been suggested that 66 character lines are the most readable.” Earlier, RFC 1855, the Netiquette Guidelines published in October 1995, advised a different number entirely: “Limit line length to fewer than 65 characters and end a line with a carriage return.” For interactive talk sessions, the same document suggested no more than 70 characters and no more than 12 lines.
The progression from 65 to 70 to 72 to 78 to 66 is not a story of increasing precision. It is a story of different documents addressing different contexts — mail, talk, flowed text, readability — and arriving at different numbers. The number has tracked display technology and reading practice, not protocol necessity.
What Format=Flowed changes
RFC 3676 is worth understanding because it represents a different approach to the same problem. Instead of asking senders to hard-wrap at 78 characters, Format=Flowed lets senders mark soft line breaks — a space followed by a carriage return and line feed — so that receivers can rejoin the lines and reflow them to fit their own displays.
The problem Format=Flowed addresses is what the document calls “embarrassing line wrap.” As plain-text messages are quoted in replies or forwarded, each line gradually increases in length, eventually being arbitrarily hard wrapped. The result is text that is hard to read and often confuses attributions. Format=Flowed allows the sender to indicate which line breaks are logical paragraph breaks and which are merely soft wraps, so that the receiver’s client can reflow the text appropriately.
This shifts the burden from sender discipline to receiver capability. A sender using Format=Flowed does not need to guess the receiver’s display width; the receiver’s client can reflow the text to fit. The specification notes that as devices with display widths smaller than 79 or 80 characters become more popular, embarrassing line wrap has become even more prevalent, even with unquoted text. Format=Flowed is an attempt to solve that problem at the format level.
For writers, the practical implication is that the 78-character line is not the only option. If your tooling supports Format=Flowed and your audience’s clients can reflow, you can write paragraphs as logical units and let the display handle the wrapping. If not, hard-wrapping at 78 or fewer characters remains the safer choice.
What to do with this
The useful question for a writer is not “what is the rule?” but “what is the receiver’s display likely to do?” The specification’s own rationale points at receiver-side display behavior. The writer’s job is to anticipate the container, not to satisfy a protocol.
A practical heuristic, drawn from the specifications themselves:
- 998 characters is the ceiling you must not cross. Lines longer than this may be rejected or truncated by transport and storage implementations.
- 78 characters is the target you should aim for in plain-text email. It accommodates displays that may truncate or wrap longer lines.
- 72 characters or fewer is a safer target when you expect quoting, forwarding, or narrow displays. RFC 3676 suggests this for wrapped paragraphs.
- Format=Flowed is worth using when your tooling supports it and your audience’s clients can reflow. It lets you write paragraphs as logical units and delegate the wrapping to the display.
None of these numbers is a protocol requirement except the 998. The rest are courtesies, extended from writer to reader, in anticipation of the container.
Why the container matters
The 78-character line is a small thing. But it illustrates a larger point about format: the container disciplines the content. A line length that was chosen to fit an 80-column screen shapes how paragraphs are broken, how quotations are nested, how signatures are formatted. The number is not neutral. It carries the assumptions of the display technology that produced it.
For writers who want to make deliberate format choices, the value of understanding this history is not nostalgia. It is the recognition that the defaults you inherit — the line length your client wraps at, the way it quotes replies, the way it handles long URLs — are not natural laws. They are conventions, with dates and documents behind them. Knowing which number is a rule and which is a courtesy is part of making deliberate choices instead of inheriting platform defaults.
The inbox is a site of editorial independence. The 78-character line is one of its small, persistent constraints. It is worth knowing where it came from, and what it is actually for.
Questions writers ask
Is 78 characters a hard rule?
No. RFC 5322 uses SHOULD, not MUST, for the 78-character limit. The hard limit is 998 characters. The 78-character recommendation is a courtesy aimed at accommodating displays that may truncate or wrap longer lines.
Did RFC 822 establish the 78-character line?
No. RFC 822, published in 1982, specifies message syntax but does not contain a line-length rule. The 78-character figure first appears in RFC 2822, published in 2001, and is carried forward into RFC 5322, published in 2008.
Why 78 and not 80?
RFC 3676 explains that the limit is 78 rather than 79 or 80 because while 79 or 80 characters fit on a line, the last column is often reserved for a line-wrap indicator. The 78-character line is designed to fit a standard 79- or 80-column screen without wrapping.
What is Format=Flowed?
Format=Flowed is a mechanism defined in RFC 3676 that lets senders mark soft line breaks so that receivers can reflow text to fit their own displays. It addresses the problem of “embarrassing line wrap” that occurs when plain-text messages are quoted and forwarded.
Should I use 72 characters instead of 78?
RFC 3676 suggests that paragraphs longer than 78 characters could be wrapped using lines of 72 or fewer characters, and notes that 66-character lines have been suggested as the most readable. The choice depends on your audience and how much quoting and forwarding you expect. Shorter lines are safer for narrow displays.
What about URLs and long words?
RFC 3676 advises that if a word exceeds 78 characters but is less than 998, the agent should send the word as is and exceed the 78-character limit. Breaking a URL across lines can make it unusable. The 998-character limit is the hard ceiling; the 78-character recommendation yields to content that cannot be wrapped.
