What is the email subject length limit?

Question

How many characters are allowed to be in the subject line of Internet email? I had a scan of The RFC for email but could not see specifically how long it was allowed to be. I have a colleague that wants to programmatically validate for it.

If there is no formal limit, what is a good length in practice to suggest?

Uwton

255 is the limit on some ticketing products (Jira for example) and seems to be the limit on outlook, thunderbird and gmail seem to truncate after 130. – Providenciaprovident

RFC2047 is better suited to validation, I see lots of bulk-mailing software producing invalid RFC2047 content. – Etiology

In databases it is very common (a tradition you can say) to define length of not especially long or short textual fields as VARCHAR(255) or similar equivalent names. If a longer string is presented, it will generate an error or simply will be truncated to the limit. That is why Jira and Outlook as mentioned here do not support more chars. For compatibility reasons I would not recommend 255+ Just adding some cream on the 5 year old cake ;) – Pyrethrum

Answer 1

See RFC 2822, section 2.1.1 to start.

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.

As the RFC states later, you can work around this limit (not that you should) by folding the subject over multiple lines.

Each header field is logically a single line of characters comprising the field name, the colon, and the field body. For convenience however, and to deal with the 998/78 character limitations per line, the field body portion of a header field can be split into a multiple line representation; this is called "folding". The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field:

       Subject: This is a test

can be represented as:

       Subject: This
        is a test

The recommendation for no more than 78 characters in the subject header sounds reasonable. No one wants to scroll to see the entire subject line, and something important might get cut off on the right.

Breslau

Current version of the IMF spec, RFC 5322, can be found here: tools.ietf.org/html/rfc5322#section-2.1.1 – Nereidanereids

Random update... gmail auto-wraps based on screen width and available space. (not 78 characters) – Miceli

This answer only addresses the line length limit, not the overall length limit. – Warily

There is RFC and there is usability. Jakob Nielsen article Email Subject Lines: 5 Tips to Attract Readers summarize as: "Focus on the first 40 characters. Descriptive and well-written subject lines allow recipients to make an informed decision to get more details or move on." – Homy

To clarify, there is no length limit for subject lines, as the standards allow headers longer than 998 bytes by wrapping a single header over as many lines as you like. The recommendation of ~80 characters is indeed a reasonable one. If you're writing an email client you have to be able to cope with ridiculously long subjects without breaking in a horrible way, preferably by truncation when showing as part of a list. – Homophony

...This would be the case with any other header field too (eg "From"). PS if you're wondering why 78 instead of 80, or why 998 instead of 1000, it's because the email standard specifies CRLF (\r\n) as separator, which is two bytes, making it 1000 bytes per line of which 998 is the header itself. Note too that the name of the header and any space after the colon eg "Subject: " has to fit in this, too. – Homophony

Answer 2

RFC2322 states that the subject header "has no length restriction"

but to produce long headers but you need to split it across multiple lines, a process called "folding".

subject is defined as "unstructured" in RFC 5322

here's some quotes ([...] indicate stuff i omitted)

3.6.5. Informational Fields
  The informational fields are all optional.  The "Subject:" and
  "Comments:" fields are unstructured fields as defined in section
  2.2.1, [...]

2.2.1. Unstructured Header Field Bodies
  Some field bodies in this specification are defined simply as
  "unstructured" (which is specified in section 3.2.5 as any printable
  US-ASCII characters plus white space characters) with no further
  restrictions.  These are referred to as unstructured field bodies.
  Semantically, unstructured field bodies are simply to be treated as a
  single line of characters with no further processing (except for
  "folding" and "unfolding" as described in section 2.2.3).

2.2.3  [...]  An unfolded header field has no length restriction and
  therefore may be indeterminately long.

Etiology

any well written email library will do this. my favourite is c-client – Etiology

This is the correct answer. The 2nd part of the question "good length in practice" totally depends on your app. If you're saving received emails then you have to support unlimited lengths. – Postfix

Answer 3

after some test: If you send an email to an outlook client, and the subject is >77 chars, and it needs to use "=?ISO" inside the subject (in my case because of accents) then OutLook will "cut" the subject in the middle of it and mesh it all that comes after, including body text, attaches, etc... all a mesh!

I have several examples like this one:

Subject: =?ISO-8859-1?Q?Actas de la obra N=BA.20100154 (Expediente N=BA.20100182) "NUEVA RED FERROVIARIA.=

TRAMO=20BEASAIN=20OESTE(Pedido=20PC10/00123-125),=20BEASAIN".?=

To:

As you see, in the subject line it cutted on char 78 with a "=" followed by 2 or 3 line feeds, then continued with the rest of the subject baddly.

It was reported to me from several customers who all where using OutLook, other email clients deal with those subjects ok.

If you have no ISO on it, it doesn't hurt, but if you add it to your subject to be nice to RFC, then you get this surprise from OutLook. Bit if you don't add the ISOs, then iPhone email will not understand it(and attach files with names using such characters will not work on iPhones).

Sabah

There are many problems with the subject you set: 1. Spaces should be encoded with '_', 2. An 'encoded-word' (=?charset?Q/B?data?=) may not be more than 75 characters long (rfc2047). 3rd You can not escape new line with '=' char at the end of the line (header QP encoding is different then body QP). Bottom line is: it is not Outlook's fault. – Hamlani

Answer 4

Limits in the context of Unicode multi-byte character capabilities

While RFC5322 defines a limit of 1000 (998 + CRLF) characters, it does so in the context of headers limited to ASCII characters only.

RFC 6532 explains how to handle multi-byte Unicode characters.

Section 3.4 ( Effects on Line Length Limits ) states:

Section 2.1.1 of [RFC5322] limits lines to 998 characters and recommends that the lines be restricted to only 78 characters. This specification changes the former limit to 998 octets. (Note that, in ASCII, octets and characters are effectively the same, but this is not true in UTF-8.) The 78-character limit remains defined in terms of characters, not octets, since it is intended to address display width issues, not line-length issues.

So for example, because you are limited to 998 octets, you can't have 998 smiley faces in your subject line as each emoji of this type is 4 octets.

Using PHP to demonstrate:

Run php -a for an interactive terminal.

// Multi-byte string length:
var_export(mb_strlen("\u{0001F602}",'UTF-8'));
// 1
// ASCII string length:
var_export(strlen("\u{0001F602}"));
// 4
// ASCII substring of four octet character:
var_export(substr("\u{0001F602}",0,4));
// '😂'
// ASCI substring of four octet character truncated to 3 octets, mutating character:
var_export(substr("\u{0001F602}",0,3));
// '▒'

Salahi

Answer 5

I don't believe that there is a formal limit here, and I'm pretty sure there isn't any hard limit specified in the RFC either, as you found.

I think that some pretty common limitations for subject lines in general (not just e-mail) are:

• 80 Characters
• 128 Characters
• 256 Characters

Obviously, you want to come up with something that is reasonable. If you're writing an e-mail client, you may want to go with something like 256 characters, and obviously test thoroughly against big commercial servers out there to make sure they serve your mail correctly.

Hope this helps!

Underdone

There's no particular reason why 256 is any better than 250, or 300, or 372. We're long past using bytes for string lengths. – Ammeter

I agree with you for practical purposes, but I think that 256 is better than some of the other options you mentioned since it is more consistent with other products. – Underdone

255 is the actual limit on some products (Jira and outlook for example) – Providenciaprovident

This answer is wrong. RFC 5322, the current version of the IMF spec, clearly defines a max line length. See @Michael's answer. – Nereidanereids

+1 The line length limitation is for all lines of the message, but I don't see anything that says you can't have a subject span multiple lines (implying no limitation on the number of characters for the subject). See 2.2.3 and the example that follows directly afterwards. – Religion

VARCHAR 255 is probably the most common (and more efficient) data column length in MySQL / MariaDB. Bytes are most certainly still relevant. MySQL will use 1 byte to store the length if it is less than 256, or more otherwise. Take a look at how C++ implements std::string if you think string lengths aren't highly important and counted in bytes. – Yaekoyael

@Nereidanereids “Max line length.” E-mail header fields can be multiline. – Dusty

Answer 6

What's important is which mechanism you are using the send the email. Most modern libraries (i.e. System.Net.Mail) will hide the folding from you. You just put a very long email subject line in without (CR,LF,HTAB). If you start trying to do your own folding all bets are off. It will start reporting errors. So if you are having this issue just filter out the CR,LF,HTAB and let the library do the work for you. You can usually also set the encoding text type as a separate field. No need for iso encoding in the subject line.

Braswell