Jay Oram
Head of Dev
1 Oct 2021
Last updated Feb 2024 - Jay
You’ve spent hours meticulously crafting your latest email marketing campaign. Your copy is singing, you’ve optimised your beautiful imagery, you’ve triple checked your links, grammar, and tracking. It’s rendering perfectly across all email clients and devices, and all stakeholders have (finally) approved! You send one final test to yourself and suddenly…Outlook strikes again.
Outlook has many known (often joked about) rendering quirks but, with some creative coding and design, most can be easily fixed or avoided. However, none are quite as infuriating or perplexing as the 1px horizontal line bug.
(The faint 1px white line in Outlook 120dpi)
What makes this bug so difficult to fix is it’s inconsistency and difficulty to replicate. On many occasions, we’ve tested the same HTML and seen the bug on one test but not another.
Parcel Unpacked Talk 2024: Pesky White Lines in Outlook
Why do lines appear?
So if it’s not a problem in your HTML, why do these lines appear?
In what many might describe as a backwards step, Outlook 2007 was the first Outlook to switch from Internet Explorer rendering engine to Microsoft Word 2007's. This meant that HTML and Cascading Style Sheets (CSS) items not handled by Word were no longer supported (and explains why pre-2007 versions of Outlook are much better at rendering HTML emails).
As an editor primarily for print media, Microsoft Word (and thus Outlook) uses points (pt) for font size instead of pixels (px).
HINT: A pixel (px) at 96DPI (dots per inch) is equal to 0.2645835 millimeters, 0.010416675 inches, or 0.75 point. It is a measurement of how tall a font is in pixels which are visible on your computer screen. So, if a font is 12 pixels in height, that means it takes up 12 pixels on your screen from the top of the letter, to the bottom, which also includes the characters that have sections which are under the guide-line, such as a “p” character.
The 'point' (pt) on the other hand is a fixed unit of length, commonly used to measure the height of a font, but technically capable of measuring any length. In applications, 1pt is equal to exactly 1/72th of an inch; in traditional print technically 72pt is 0.996264 inches, although I think you'll be forgiven for rounding it up!
Why is this an issue? While Microsoft knows about the bug (and so far have been silent on it), testing suggests the bug appears when Outlook converts pixels to points and ends up with a decimal number. As a pixel is 0.75 of a point (at 96DPI), our pixel values can end up uneven (e.g 18px X 0.75 = 13.5pt).
The 1px line comes from Outlook converting px to pt - and if that ends up odd - like 13.5pt, the remaining 0.5 can cause a tiny white line.
Another theory about the white line is that it is a UI bug and nothing to do with your HTML - I know it’s no consolation when your client keeps getting it, but the way the window is set up, the Ui font-size, dpi settings on Windows, even just using the text zoom provided in the interface, can all lead to the bug appearing.
Prevention
Keeping all numbers divisible by 4, if possible?
Make sure font-size, line-height, padding, margin and any other coded pixel numbers are divisible by 4 and you could mitigate it being a problem.
Keep tables/sections short and contained.
Try splitting the email into manageable smaller sections, often called modules. The more pixels being added together, the higher chance of coming out with an odd point amount. This will also allow you to narrow down where a problem is, if a white line occurs.
Remove borders on table and images
By doing this, you remove extra lines, enforced padding and other issues that come with these attributes.
display: block or vertical-align: middle
Using display: block or vertical-align: middle on img elements to stop extra margin being added.
Retina images divisible by 4!
When using 2x size images (retina) ensure they are divisible by 4, both the width and height.
Common causes
Zoomed in on Outlook Desktop - if you have set heights and not everything is using relative units, sometimes 1px gaps will appear at odd levels of zoom, I can’t count how many times someone has said, “It was caused by the recipient having 125% zoom.”
Borders - If you are stacking images with links on top of one another, some versions of Outlook will add a border surrounding the image or element. By ensuring border=”0” or border-collapse: collapse is set or that no border is set on elements, you can save yourself a headache.
Images display default - img elements are by default display:inline therefore behave like text and any gap after them in the code will be treated as a space. Often when adding an image in a container, the closing tag is on the line after, and this adds a 4px gap. This can be confused with the 1px white line bug or add more pixels into the mix. By setting all images to display:block, this gap will be removed.
Using Retina images? - If you are using retina images, or images twice the size to enable better rendering on retina(higher resolution) screens. If the image height cannot be divided by two and not have a decimal, the remainder could cause a 1px line. For example, an image 200px x 200px when displayed at half the size would work out to 100px x 100px - this should not cause an issue. But if your image is 205px x 205px - this when halved would become 102.5px - adding an odd number into the mix.
Table background color - In some instances the white line occurs within another colored table. This occurs for the same reason, numbers just not adding up! But also due to <tr> and <td> tags having default heights. By placing the surrounding color in the cell closest to the next background color there is less chance of a 1px line being seen.
For example the code below produces a thick black table cell with an orange table nested inside:
But this code will produce a thinner black outer table cell:
Padding/Margin - As mentioned above the bug is due to calculating sizes and all layout attributes are taken into account. Starting from the outside, moving in and try to see what could be causing an inconsistency - margin > border > padding > element
Solutions
Okay, so you have tried to prevent white lines, you’ve kept tables small, tried to keep even numbers throughout, but something is still causing it.
Below are a whole bunch of solutions I have used or been told about since starting as an email developer. Starting with the easiest to implement, to more drastic solutions.
It is worth noting that while one of the below fixes will work on one HTML document, it’s not guaranteed to work on a different HTML doc. In some cases, you may need to apply a mixture of the techniques to solve the issue, although again there are no guarantees.
Adding background color
One way to stop the white line being a problem is to choose to use white as a background color (not really a good solution, but can solve it!) But a bit more help may be the choice of using a suitable color on the html or body tag.
The color may be getting pulled from the html or body tag so setting them using
html, body {background: #e1e0db;} could pull the correct color through into the 1px gap.
Alternatively wrap all the content in a table and add the correct background color.
Add a <br>
Sometimes this is all that is needed to even out all the inconsistencies. If adding a <br> tag doesn’t affect the overall design and layout for other devices, you’re done! To add a break for only Outlook Windows you can use mso conditional comments. For example the below will target all versions:
HINT: for specific versions, check out howtotarget.email and type in Outlook!! Unfortunately after Outlook 2016 - they stopped naming versions in comments, so Outlook 2016/Windows 10 Mail/Outlook 2019 are all mso 16.
Margin/Padding
Yep - now you have made sure all your numbers are even, find the closest padding/margin tag to the bottom of your table and add/subtract a pixel at a time to see if it will fix it.
Add margin-bottom
If the white line is at the bottom of a table or element, try adding margin-bottom: 1px; or wrap the content in a <div> with margin-bottom: 1px.
Add an empty row
Creating an empty row with 0 font size and line height with a will create an extra element that could smooth out all the issues. For example:
Nest the offending <table>
This is a good go to for padding/margin issues in Outlook - by nesting the content inside another table it could compound the problem, or could sort it by adding extra pixels.
Forcing the font-size and line-height to zero
If your table contains mainly images, you can add font-size:0;line-height:0; to the inline style on the table. Ensure all text inside the table, and images are given an inline font-size and line-height as well (don’t want alt text to disappear!).
Forcing font-size, line-height and border-collapse across the email.
This solution is drastic and can affect a lot of rendering so use with caution! This has been recommended to me a number of times, but I’ve as yet not needed to use it.
You could set the style in the head to affect all the table rows <tr> and table tags in your HTML but only for Outlook, the below example specifically for Outlooks after 2013:
border-spacing: 0;
Wanted to share everything! Some suggestions use border-spacing:0; in setting styles in the head or ‘reseting’ email client styles. The initial value (default) is 0, so shouldn’t need to be set, but could be worth a try!
Coding for this in a Design System
When coding an Email Design System, it’s impossible to know what content could be used in it (e.g text length, image height, copy etc). Unless of course you create a very strict Email Design System with, for example, fixed image height or character limits. But here’s some helpful tips that should suppress the issue as much as possible.
Use numbers divisible by 4
If you are setting up a design system, use a base of round numbers, from font-sizes, to suggested image sizes.
Keep modules self contained
Try to keep each of your modules as it’s own self-contained table (no wrapping table).
Keep modules short
Arbitrary heights have been thrown around all over slack, twitter and forums, but ultimately keep containing tables short and split everything up.
Define sizes
Where possible, define specific font sizes and image sizes and test these, a good combination of even numbers and well defined size rules will go a long way to ensuring the dreaded white line doesn’t appear.
Using email editors/WYSIWYG/drag and drop builders?
A trick that we found out recently, if you can’t enter in the HTML there are keyboard shortcuts!
Mac: Option + Spacebar
PC: Ctrl + Shift + Spacebar
MJML
If you are using MJML - all of the fixes mentioned can be added in an <mj-text> element, which will be left as is.
Summary
A bug often discussed and debated, with a mysterious origin, no solution from Microsoft and a whole bunch of other solutions.
At some point Outlook 2019 will be retired (Rumoured to be 2026 !!) and Outlook are moving away from the Word rendering engine 🎉 with a move to 'One Outlook' - which has already seen Outlook webmail, Outlook Mac and Outlook app start to share rendering engines.
Hopefully we have shed some light on the issue and what we are 99% sure causes them and a long list of possible code and design solutions.
Keep your numbers divisible by 4, your tables short and your image height divisible by 4…
Resources across the web
https://github.com/hteumeuleu/email-bugs/issues/99
https://litmus.com/community/discussions/5286-mysterious-white-line-in-outlook
https://github.com/TedGoas/Cerberus/issues/115
This Blog post was originally posted in 2021 - from both Jay Oram (Head of Dev - ActionRocket) and Ben Tweedy (EDS Developer Taxi for Email)