Email newsletter truncation in iOS Mail

By Ros Hodgekiss on 29th November 2012

Ever had your newsletters get cut off by the 'This message has only partially downloaded' prompt in iOS Mail? Preventing it from appearing may be a mix of keeping your message short and sweet, then simply trial and error.

If you test your email designs on an iOS device like the iPhone or iPad, you've likely seen the following message:

Truncated email in iOS Mail

While having your messages temporarily truncated may appear to be a mild annoyance, it does bring with it a silent issue - unless the email is fully downloaded, the open may not be recorded. While Email on Acid wrote an authoritative article on this less than a year ago, it seems that conditions have changed since then.

What triggers this message?

From our tests, we were able to reliably trigger this message by:

  • Making the HTML file size greater than 15kb. This total does not include images or the plain-text version, both of which seem to have no impact on whether this message gets triggered.
  • Downloading the message over cellular data, not WiFi. In a way, this is to be expected, given the cost of data in some countries.

As you can imagine, it's fairly easy to make the 'partially downloaded' message display - all that's required is a fairly-long newsletter with a comprehensive stylesheet for good measure. Unlike EoA's determination that only POP mailboxes are affected, we found that this could be reliably replicated in clients using IMAP, too.

In addition, we tested on iPhones running iOS 5 and iOS 6 and found that both truncated messages that exceeded 15kb and were accessed over cellular data.

Trial, error and sometimes even a fix

What makes this issue so mysterious is that it's sometimes possible to send HTML file sizes that are larger than the prescribed 15kb limit without triggering this message. In one test, we were able to dismiss the message repeatedly by removing the opening <body> tag. However, when this fix was applied to another newsletter, the message appeared, much to our chagrin. While EoA suggests this can be remedied by ensuring that there are more than 1,019 characters before the closing </head> tag, in the case of our successful <body> tag tests, we were able to get away with far less.

To avoid this message, your safest bet is to keep all email newsletters short and sweet, thus steering well clear of the 15kb danger zone, wile keeping in mind that inlining your CSS may also bump up the file size. Removing line breaks using a tool like HTML Minifier can also help keep file sizes down, but it will also make your code relatively unmanageable, too.

But at the end of the day, if the upper portion of your email is engaging, it's likely that folks who come across this message will choose to download the rest of the newsletter. So if anything, the best remedy is to ensure your content is interesting and relevant enough to make readers want to read more.

Have you had your email newsletters truncated? Is there another workaround? Let us know in the comments below.


  • Paul Farnell
    30th November

    I’ve seen this be a bigger problem if your HTML structure is such that cutting your content off halfway causes some weird layout issue as a result. Your message could end up getting rendered with lots of unclosed tags part of the way through.

    Naturally it’s somewhat of an edge case, but combined with the iPhone’s auto resizing/scaling emails can end up looking funky.

    Breaking your template up by having completely separate tables for each major section could help avoid having as big an impact.

  • Eyal B
    1st December

    I’ve contact you about a year ago regarding this issue and I found that if HTML by it self (regardless of images and plain text) is larger than a 100kb it will show the annoying message.

    Also it is important to remember while attaching and uploading your custom HTML on Newsletter Service Companies they wrap your code with their own additional code and standards—which could add few more kb.


  • Michelle Klann
    8th December

    Thanks for citing us in your blog Ross!  Yeah it took me an entire day to identify the character count fix. 

    I noticed you didn’t include our second fix which is to remove the head tags entirely.  Be careful with this solution, some email service providers might place head tags within your email dynamically.

    One final note, I recommend that people stay clear of HTML Minification when it comes to HTML emails, particularly when removing line breaks.  While testing our new product, Mozify, we learned that Gmail and Live Mail have a maximum number of characters per line (near or around 720 chars).  Once it reaches the maximum, it creates a new line break even if it happens to be in the middle of an HTML element.  For example: <t
    d>. Not good :(


  • Spiros Martzoukos
    18th December

    Thanks for the insightful article Ros. It’s good to see the big players in the industry work together to resolve issues (and kudos to Michele for the useful 720 chars tip).

  • Spiros Martzoukos
    18th December

    I’d also like to share with you the results of some of our tests:
    - I added the 1019 characters fix in a 25KB email and it worked
    - I removed the 1019 fix from it and the same email failed (showed download prompt)
    - I added the 1019 characters fix in a ~50KB email and it failed

    I would also like to introduce a new parameter to the discussion, which is the final size of the email as it arrives to the client. Although the HTML of our tested email can be 20-25KB, with the addition of the text version, the prepending of the headers and the insertion of the =line-breaks= and =character-encodings=, the email can very easily double in size (which, btw, happens to be the case with my first test above).

    I’m not an iOS developer but if the size is the crucial factor for the email cut-off, my best bet would be on the size that the client receives rather than the one of the HTML version only. I could try doing some tests with this size in mind in case this yields more precise results regarding the size.

  • Ros Hodgekiss
    19th December

    Hey guys, I’m so glad we’re collaborating on our findings here. The observations regarding line breaks and ESP-provided code are well salient and are great to keep in mind when trying to steer clear of this truncation issue.

    Spiros - We’d love to hear what you find if you continue testing. This is very useful stuff and could be of a lot of benefit to others. Thank you :D

  • Michael Skelly
    5th January

    Hi. I came across this problem. Doing some quick testing I noticed that removing ALL spacing fixed the problem. A quick few more tests showed that if I reverted to normal and simply removed all indenting of the HTML in the email it also solved my problem.


                                      some content


    some content

    My very quick rough guess based on that is that while iOS checks the size of the html in the email IT ALSO checks the percentage of whitespace within each email to decide whether to truncate it. iOS probably does something like this:

    if (email size > 100kb) OR (percentage whitespace > 50%)
      -> truncate!!

    However I could be wrong…

  • Michael Skelly
    5th January

    oops above not displayed properly..  synopsis - basically I didn’t indent my html.

  • Ryan Killeen
    16th July

    Just wanted to thank everyone who participated in this, it has been a huge help, and undoubtedly saved me hours of frustration.

Got something to add?

Sign up for free.
Then send campaigns for as little as $9/month

Create an account