Editing MIME (section)

====alternative====
The multipart/alternative subtype indicates that each part is an "alternative" version of the same (or similar) content, each in a different format denoted by its "Content-Type" header. The order of the parts is significant.  RFC1341 states: ''In general, user agents that compose multipart/alternative entities should place the body parts in increasing order of preference, that is, with the preferred format last.''<ref>{{cite web|url=http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html|title=RFC1341 Section 7.2 The Multipart Content-Type |website=World Wide Web Consortium |access-date=2014-07-15}}</ref>

Systems can then choose the "best" representation they are capable of processing; in general, this will be the last part that the system can understand, although other factors may affect this.

Since a client is unlikely to want to send a version that is less faithful than the plain text version, this structure places the plain text version (if present) first. This makes life easier for users of clients that do not understand multipart messages.

Most commonly, multipart/alternative is used for email with two parts, one plain text (text/plain) and one [[HTML email|HTML (text/html)]]. The plain text part provides backwards compatibility while the HTML part allows use of formatting and hyperlinks. Most email clients offer a user option to prefer plain text over HTML; this is an example of how local factors may affect how an application chooses which "best" part of the message to display.

While it is intended that each part of the message represent the same content, the standard does not require this to be enforced in any way. At one time, [[Email spam|anti-spam filters]] would only examine the text/plain part of a message,<ref name=AntiSpamOverview>{{cite journal |url=https://www.irjet.net/archives/V4/i1/IRJET-V4I169.pdf|title=Overview of Anti-spam filtering Techniques |journal=International Research Journal of Engineering and Technology |volume=4 |issue=1 |date=January 2017 |s2cid=212596952 |access-date=2020-02-20}}</ref> because it is easier to parse than the text/html part. But [[spammers]] eventually took advantage of this, creating messages with an innocuous-looking text/plain part and advertising in the text/html part. Anti-spam software eventually caught up on this trick, penalizing messages with very different text in a multipart/alternative message.<ref name=AntiSpamOverview/>

The type is defined in RFC 2046.<ref>[https://tools.ietf.org/html/rfc2046#section-5.1.4 RFC 2046, Section 5.1.4]</ref>