This is an old revision of the document!
Notes on Plain Text vs. HTML Mail
Contra HTML mail
- Ecologically expensive due to increased size of messages
- High complexity
- Harder to develop, hence more expensive
- Handling more likely to break (e.g.
Kaputte Zitate im Plain-Text von Gmail)
- Less transparent; errors are harder to debug (for users and developers)
- Higher hurdle for first time users (e.g. for newsletters)
- Security hazards (cf. security bug fixes of main mail programs such
as Security Advisories for Thunderbird)
- Privacy hazards (e.g. HTML is used to track users)
- Some automated systems (e.g. mailing lists) do not accept HTML and will
reject messages, or use only the alternative plain text part, or convert
the HTML potentially causing formatting issues.
- Requires HTML aware software
- Double effort (HTML and text need to be formatted and checked)
- Little guarantee that HTML will be shown as intended
- More distractions (e.g. font selectors, emoji buttons)
- Harder to write (formatting takes more time)
- "Angry fruit salad": Every user chooses a different font in a different
color and different size.
Pro HTML mail
- Ability to format and style the message content
- Ability to create "rich" content (graphs, tables, ...)
- Ability to use semantic markup (e.g. to mark text as preformatted)
Contra plain text mail
- Text wrapping issues if lines are hard-wrapped (not format=flowed)
(e.g. on mobile devices with small screens)
- Text formatted for fixed width fonts might get distorted
- Some content is better sent as attachment (e.g. illustrations)
Pro plain text mail
- Easy, small, ecologically friendly (compared to HTML mail)
- Text is shown by all devices and programs
- Accessibility as good as it gets
Criteria to consider
- False positive spam: It is unclear whether HTML mails are more likely to be falsely categorized as spam.
- Accessibility: It is unclear whether HTML mails that include alternative plain text parts are less accessible, for instance for text to speech conversion.