Solving DPI scaling issues with HTML email in Outlook

Solving HiDPI scaling problems in HTML email on Outlook 
Improve HTML email for HiDPI users

So after my write up over on the Campaign Monitor forums about the problems with DPI scaling with HTML email on HiDPI devices i.e. my XPS 15 9530, a lot of development has been made in understanding why HTML emails are rendering poorly in Outlook with large scaling factors used. Once again, community forum member Michael Muscat provided a very detailed write up on the situation originally over on the Litmus Community forums covering some of the information I discovered, along with some new workarounds and one of the most critical fixes being for images, which we’ll get into shortly. Big thanks to him for this new information that’s come to light.

DPI scaling in general terms is a known problem in Outlook, but on HiDPI devices its even worse and most of the HTML email campaigns I have received have been broken in some way that affects the layout massively.

For testing and experiments I used the following Outlook clients versions under the following conditions:

  • Outlook 2007 (Windows 7 200% scaling)
  • Outlook 2010 (Windows 7 200% scaling)
  • Outlook 2013 (Windows 8.1 200% scaling)

The common dominator here is all these versions of Outlook use Microsoft Word for rendering email, so while they severely lack any HTML/CSS standards, they virtually render email in the same way, meaning the problems with DPI affect all three versions. Even older versions of Outlook may also be affected, but their usage statistics are rather low, so focusing on these clients makes more sense.

The problems with Outlook and DPI (summarised)

  1. Width and height HTML values in pixels on various elements are not rendered correctly
  2. Images don’t render correctly when factors greater than 96 DPI are used

Because of this font sizes often appear out of proportion compared to rest of the email.

Problem #1: Emails that use pixel values for width/height

Welcome to the first problem of HTML email with HiDPI in Outlook. You will notice emails that end up in the inbox on such a device will appear squished up.

Take the Email on Acid example email below (by the way, I’m not hating on you guys and gals or anything, you just landed in my inbox and provided me with a perfect demonstration!)

Email on Acid

You’d agree that the width is far too small right? Well would you be surprised to learn that the width value defined in this email is 580px? Its true, but any pixel guru’s out there knows that’s not 580px visually. Actually, its half the size it should be. You’ll also notice that the black header block isn’t squished up, why? Simple, because the width value is 100% which is a relative value. We have our first discovery.

Outlook handles HTML px values differently with higher DPI settings

Taking this nice summary from Michael, this is how Outlook looks interprets widths in various forms.

  • All widths and heights defined using HTML attributes are perceived as pixel values.
  • All “px” widths and heights defined in VML shapes are perceived as pixel values.
  • All other “px” values are converted into “pt” values.
  • Desktop scaling is applied to relative units like “pt”. For example, 10pt @ 150% desktop scaling would be equivalent in size to 15pt @ 100% desktop scaling.

Now you know your enemy a little better, but how can we fix this? The fix is actually rather simple. For HTML width and height attributes applied to block level tags like <table> and <td> you simple need to declare a matching CSS width and height property.

<!-- Wrapper table, as this is a relative width, nothing new is required here -->
<table border="0" cellpadding="0" cellspacing="0" width="100%">
       <td align="center" valign="top">
           <!-- Container table, specify a CSS width in conjunction with the HTML width attribute -->
           <table border="0" cellpadding="0" cellspacing="0" width="600" style="width:600px;">
                   <td align="left" valign="top">
                       <!-- The rest of your template here -->
        </td> <!-- End Container table -->
</table> <!-- End Wrapper table -->

Doing this will allow your px widths to be interpreted correctly as you’d expect. Score.

Problem #2: What’s going on with my images?

So after figuring out why emails appeared squished, the next problem you’ve probably noticed is the rendering of images isn’t quite right. Problem number two. Image scaling in Outlook is poor when the DPI is greater than the default of 96 DPI. See the comparison below:

Email on Acid email footer in Outlook 2013:

OA email footer in Outlook 2013

Email on Acid email footer in Internet Explorer 11 (View in browser option via Outlook):

EOA email footer in IE11

To illustrate how width and height values differ with images in Outlook with DPI, here’s an example image at 248px x 68px with the code to go along with it:

<td align="left" width="244" height="68" style="width:244px;height:68px;" valign="top" bgcolor="#000000">
    <img src="/path/to/image" alt="Something Descriptive" style="display:block;" width="244" height="68" border="0" />

Image within a table cell

After applying the CSS width and height properties to correct the HTML width on the table cell, you can now see how smaller the image is rendered. Notice that both the image and table cell are both the same width and height, but the image isn’t.

Its worth noting here that Outlook isn’t actually modifying the size of the image itself at all. If you were to save the picture from within Outlook it will be the exact size of the original image. It is all to do with scaling.

Outlook can scale images (sort of..)

You may be surprised to learn that Outlook can scale images, but not immediately when it lands on the inbox. From tests the images appear half size in the preview pane, even with images on or off they are drawn incorrectly, however once the images are downloaded and the email has been opened up separately, images do get scaled up. It is however a process that is triggered sometimes so its not reliable. There is also however a very big catch 22 to this.

In order for Outlook to scale images you must not declare any width and height attribute on the image tag itself, otherwise this prevents it from ever happening. This goes against best practice in regards to image in HTML so what do you do? The preview pane problem remains however, images always appear smaller than they should so the answer is relying on Outlook to do it on its own isn’t an option.

Documentation dating back from Microsoft Office 2000 provides the answer (no really!)

This is where Michael Muscat and his experiments picked up where I left off, all of the image based handling discoveries are solely down to him! Outlook can be forced to render the images correctly with some clever XML directives that only Outlook understands. It requires you to make some adjustments to your template first.

Additional XML namespaces:

You’ll first need to amend the root HTML tag in your template to incorporate some XML namespaces that Outlook will need to understand the special directives that are going to be used.

<html xmlns="" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office">

The first part is to enable VML support, what is VML? Its a subset of XML specifically for images and shapes that is supported in Microsoft Office and hence Outlook 2007, 2010 and 2013. While VML isn’t required directly to fix this, Michael did some experiments with VML which helped lead to the discovery below. The second part is to enable the Microsoft Office namespace for use in Outlook.

Normalise the DPI of images (which is referred as PPI by Microsoft Office):

This is where the magic is, you’ll now need to place this Microsoft Office specific code in the head section of your template, it should be included right before the closing tag of the head.

<!--[if gte mso 9]>

This snippet will now scale up your images upon landing in the inbox, meaning the preview pane will display the images properly, along with when the email is opened separately making whole email looking more like its 96 DPI counterpart that you probably dreamed of seeing on HiDPI. You’ll notice some quality loss on the images i.e. jpeg, but overall it works well.

Why does this work?!

Well, first of all remember when I said documentation dating back to Microsoft Office 2000 helped solved the problem? I wasn’t lying. In fact Michael said he had help from a complete reference of XML in Microsoft Office over on MSDN to help find a solution. The link is a download for a HTML (ironic) help guide that details various properties dating back to Office 2000. You might not know this, but in order for Microsoft Office content to be potentially usable in webpages (back in the day this is) it supported (and still does) HTML, CSS, XML and VML. Of course there are limitations to the support level for these languages, but this is the underlying factor as to how its possible to use such properties in Outlook.

OfficeDocumentSettings is the containing tag, but in this case it acts as the container for various document properties, don’t forget this is the Word rendering engine so the term document is actually what email is to Outlook 2007 onwards, a Word document. Within the OfficeDocumentSettings tag the following properties can be used, most of them not really relevant:

AllowPNG, Colors, DoNotOrganizeInFolder, DoNotRelyOnCSS, DoNotUpdateLinks, DoNotUseLongFilenames, DownloadComponents, LocationOfComponents, PixelsPerInch, ReadOnlyRecommended, RelyOnVML, TargetScreenSize

The golden nugget in this case is PixelsPerInch, being able to force a specific DPI setting fixes the image problem beautifully. AllowPNG is not strictly required, but potentially by using it you can gain some image quality and decreased file size (and overall image download time).

A caveat for Outlook 2007

Unfortunately sometime after writing this article, I found Outlook 2007 has some behaviour differences when modifying the PPI value. A community member on the Litmus Community member mentioned that this fix didn’t work for her and images were still were still not being rendered correctly in Outlook 2007. Intrigued I did some further testing. What I found is a different behaviour and hence rendering of images when modifying the PPI value.

125% scaling (120 DPI):

  • 72 PPI – Enlarges images a lot
  • 96 PPI – Enlarges images slightly
  • 120 PPI – Images are displayed at the correct size

100% scaling (96 DPI):

  • 72 PPI – Enlarges images by a lot
  • 96 PPI – Images displayed at the correct size
  • 120 PPI – Shrinks images (erm what?)

Compared to the later versions, Outlook 2007 has a different way of handling the PPI with DPI scaling factors, it looks like Microsoft since changed this behaviour, maybe as a bug fix or simply by design, either way however you’ll notice the difference of what each value of PPI does under Outlook 2007.

The inconsistent image scaling factor difference between 100% scaling and 125% scaling (as well as others) means you can’t fix the image scaling problem for Outlook 2007. Because whichever way you go, you will break the appearance for either the normal DPI audience or the higher DPI audience. There is no way to conditionally target any Outlook client by DPI (only by Microsoft Office version). This means by forcing the 96 PPI value, you’ll still find images will be slightly larger than they should be for clients using DPI factors greater than 96, but in my opinion forcing 96 as the PPI will still make things a bit better.

A workaround in this case is to develop your layout in such a way that will allow the image to push your layout wider, rather than break out and overflow, it certainly won’t look as pretty, but its damage limitation

Let me know your results

Improving HTML email on HiDPI may not be a priority for you when it comes to development time right now, but with HiDPI devices on the rise with Windows 8.1 and future versions, its a good time to understand how Outlook handles DPI and how you can make your emails looks better for these type of Marketing list members! There is also the consideration of users who use large DPI factors for accessibility purposes as well.

All of the information here is fairly new, and hence hasn’t been tested thoroughly, I’ve tried to get a broad range of clients and environments to test everything out and haven’t found any bad side affects. I’d love to know if anyone else has been testing this and what your results and thoughts are. You can post your thoughts in the comments below or join in the discussion over the Litmus Community forums. You can also find the original article I started on the Campaign Monitor forums

Once again, big thanks to Michael Muscat and his input on this, couldn’t of done it without him!

Share This:

  • Jens Wetterich

    Do you have found a General solution for users? I am not creating HTML emails, but just reading them and these issues are really annoying. I am using Thunderbird atm now.

    • Generally such problems with DPI are reliant on three areas:

      1. How the email is coded
      2. The email client being used and if its DPI aware.
      3. The OS the email client is running on and how it handles higher DPI settings.

      I haven’t looked at Thunderbird, but now you’ve mentioned it, I’m going to check it out. My initial comment would be perhaps Thunderbird is not optimised for HiDPI. This article was mainly about Outlook.

      • Jens Wetterich

        Hi, thanks for the fast reply.
        to 2) I like to use Outlook 2013 – but scaling is too bad. Because of that I am using Thunderbird 24.4, where scaling works perfect, but the program is a bit uglier. 🙁
        to 3) I am using Win 8.1 on a XPS 15 9530 like you.

        And I am waiting for a general solution for Outlook users, not the email creators. But I didn’t even find a possibility to submit bugs to MS… There are not only the problems with HiDPI, but also problems with MultiDPI in Powerpoint e.g., that I’d like to submit somewhere.

        • Snap, a fellow XPS 15 9530 user! 🙂

          Unfortunately, Microsoft couldn’t provide any user side fix for this. I logged a support case with them and it got passed to the Outlook support team, after a few emails and phone calls no resolution was found. I don’t know if the actual Outlook dev team ever got visibility of it though.

          The only way I know of currently is to fix is in the email template with special XML directives to force image scaling, so you are reliant on the email sender I’m afraid at this point.

          However I feel your pain, because most of the emails I get through these days are borked in some way.

          Email campaigns and DPI is something that hasn’t been talked about much, that might change as more and more HiDPI devices arrive on the scene.

          • Jens Wetterich

            Yes another XPS 15 9530 user. Do you experience the problems with the coil whine issue too? 🙁

            Okay.. Not so great from Microsoft. But it is possible for them to fix it – in Thunderbird scaling works well too, so it can be fixed. They just have to work on it. And I think a fix from Microsoft is easier then changing to whole way of creating email campaigns.

            But in general many programs aren’t HiDPI ready yet. Chrome is another example, in the Canary build it works now – but I have always other problems because of the early adopter thing..

            So.. What is the best way to get Microsoft to fix the last HiDPI and MultiDPI Bugs in Office and Windows? 😀 Maybe Win 8.1 Update 1 will help?

          • Mine does like to emit some low level whines sometimes, but I’ve got used to it. One of the fans however has started to buzz which is a bit annoying! I may use my warranty for a Dell tech to service it at some point, it is however my primary dev machine, and therefore taking it out of service isn’t easy!

            In my opinion, Office 2013 apps scale well with HiDPI in relation to the UI. Scaling for emails and the preview pane in Outlook however is very poor.

            HiDPI is something that Microsoft have only recently started being serious about. Windows 8.1 is essentially the first version that can support HiDPI devices. I’m sure further API and under the hood improvements are present in Update 1, but I don’t think it will change anything dramatically. In fact, I can tell you right now that Update 1 has changed nothing in relation to Outlook as I’m already running it. Likewise I also have SP1 of Office 365 installed, and again no improvements.

            There is responsibility on the Application Developers side to update their code to support HiDPI too. Google Chrome being a good example. Another is Adobe with its Creative Cloud suite, some apps work on HiDPI, others don’t, though there is a bit of a blame game culture going down with Adobe vs Microsoft right now.

            The unfortunate fact is you are almost guaranteed to come across applications that are not DPI aware, even Microsoft apps. Shocking but true. The thing is Apple had the same problem in the beginning, but because they jumped onto the HiDPI scene first, they’ve got Application Developers on side now and have available API’s for devs to use. Microsoft are now experiencing the same problems Apple did, there API’s are still new and perhaps need work still.

          • Jens Wetterich

            Thanks for the reply!
            To the noise: Mine is really loud and very annoying. Recently I had the problem with the fan too, I called Dell and they sent me a tech supporter to repair it (I have 3 y. NBD). There was some wire in the fan and they replaced it and now it’s gone.

            In general I agree with you. Office is one of the better scaling apps. but I use a second FHD screen with 24″ (so no HiDPI) and Office (especially Powerpoint) has some problems with that screen then.

            Bad to hear that Win 8.1 Update 1 and Office 365 (I am using the University version btw) SP1 doesn’t improve the situation. I hope there are some “small” updates coming soon fixing some issues.

            I hope Microsoft starts feeling some pressure to work on the issues soon, when Adobe and other companies are faster then Microsoft.

          • Michael Muscat

            While HiDPI looks amazing, it might be better to lower the resolution if you need to get actual work done. Reducing the resolution from 3200×1800 down to 1600×900 will still look reasonable since it’s pixel doubling, then you can set DPI scaling back to 100%.

          • Jens Wetterich

            Yes but it looks so blurry then.. 🙁

  • dcrystalj

    So this is only for sending email tutorial?

    Or whre is this css file to fix reading on full width?

    • This fix needs to be applied by the sender in the email template.

      • dcrystalj

        oh, to bad, its weird that even microsft send me email without this hack you have provided..
        i just found out that if i zoom to 200% it’s much better but the problem is that Outlook 2013 cannot remember zoom for all reading mails

        • They weren’t help much with me either. Zooming will help, but things will be out of proportion in most cases, and as you say, zoom persistence won’t be maintained in a lot of cases. Essentially the PPI setting forces Outlook to render images at the correct size, but forcing this on client side doesn’t seem possible.

          All of the adjustments for HiDPI however must be done on in the email template sadly. The alternative is opening emails in IE, in most cases Outlook should provide that option, and most email senders leverage this option with a certain CSS directive, but quite frankly its not a solution

          Unfortunately, I don’t think many email senders are aware of this behavior with Outlook 2007+ and HiDPI devices. Microsoft weren’t that’s for sure.

  • Jon

    Sweet! This fixed the issue for us. Was racking my brain trying to figure out the cause, until we realized the user that was having the issue was due to a PPI scaling issue with their laptop. Adding the XML namespaces to the html tag, and then adding the XML to the head worked flawlessly.

    • Yes, without controlling the PPI value Outlook uses, if a user has their DPI set to anything greater than 100% you will see image content being manipulated in Outlook 2007 – 2013.

      Unfortunately, this won’t quite fix the issue in Outlook 2007, because the value of 96 PPI will still enlarge images slightly, however it works great across Outlook 2010/2013 over multiple DPI scaling factors.

  • Diogo Almeida

    Something like this is happening in my email signature. I can i solve it there? Outlook signatures are quiet strange to build…

  • Brandonhyl

    Excellent! I’ve been troubleshooting this issue for a couple days now
    and your tutorial was spot on in getting me to a nice end result.

  • Tamtam

    After hours of playing around I finally figured out how to add a background image to your emails, edit with word and not have it repeat or resize. First you have to make your background image massive with your graphic on the top left and the rest of it white to give it the illusion it’s not repeating. Make sure when you are setting up this file in photoshop it is at 120 DPI. When you are done do a file > save as, then save as a JPG. Gif will not work, it’ll change it back to 72 DPI. Save for web will not work, it will change it to 72 DPI. After you save this file I’d suggest opening it in photoshop and checking to see if it’s still 120 DPI. I spent way to long trying to figure this out so hopefully this comment will save someone a bit of time.

  • Matt Kimont

    James, you save my life today 😉 Thanks a lot for this article !! Have a great day Mate !

  • Larry Mandelberg

    Is my problem solved…maybe?

    My Outlook 16 on my brand new Surface PRO 4 is not displaying emails with HTML body correctly. Toward the bottom of your post titled “Solving DPI scaling issues with HTML email in Outlook” you say ‘Let me know your results’ which is why I’m posting. I think your solution to add the ‘Microsoft specific code’ (snippet) that begins with “ to the “…head section of your template…right before the closing tag of the head.”, how do I access ‘the template’ to insert that snippet? I haven’t written or edited code in 20+years and not a programmer by current standards although I do understand it and am 100% confident that if I can find where to edit the template as you describe, I can get the job done. How/where do I find it?

  • Very helpful post and comment thread. I’ve tested the image scaling solution with Outlook 2016 on a high DPI machine, and I can confirm it works.

    But what if I want to develop templates to send from Outlook? Outlook seems determined to strip out the XML conditional magic listed above.

    • #VuppeForPresident

      Exactly my problem. My client sent me old .eml files that don’t have the scaling problem and ask “why can’t you do this properly?” but I am unable to find a solution, even using eml myself.

    • I am having the same issue. Adding the code doesn’t fix the issue and reviewing the email source code shows that the code above is missing.

      • We ended up building templates that use images only minimally—and only in places where they can’t bork the layout. It’s the best we can do until Outlook dumps its janky HTML rendering.

      • A preprocessor is likely stripping the MSO XML code at the send, so the fix is being removed when it arrives in the inbox.

  • Christian Gosch

    Very useful post!! However I found that the MSO XML stuff TOGETHER with HTML width / height attributes works at least for Outlook 2010, even if the delivered image has “wrong” dimension data. Thus I decided to deliver inline CSS values as well as HTML attributes for width and height (but watch out for CSS “width: 100%;” witch has no HTML “width” equivalent!). The same is valid for “no border” requirement, which I declared as CSS “border-style: none;” as well as HTML attribute “border=’0′”. —

    The problem “TD is rendered too high even if explicitly sized” applies usually to elements which should appear “as a border line”. In these cases one can wrap the whole thing in a TABLE TR TD which in turn has a CSS “solid 1px #666” border style, and HTML attributes “align=center”, “bgcolor=#666” and “border=0”. The “real” (inner) content should then be decreased by 2px in width to match the original planned total item width. This at least causes reasonable results, even if there are problems with borders etc.

  • tessachka

    Thank you! This post helped me figure out a issue that stumped me for a few weeks.

  • Rombout

    sorry for asking ive got this piece of code for a email signature. there is a image for the logo which is actually 400px width but i scale it down to 200px, so its sharper.

    Ive now added the part style=”width:200px; height:92px” will this make sure it doesnt upscale again? Its hard for me to test on mac

    • You don’t actually need to use the width and height CSS properties on an image in this case. You can simply use the width and height attributes on an image directly. You shouldn’t however declare a width or height attribute with a px value, it should only be a numeric value only. So in your example, width as 200 and height as 92. Assuming the actual image size is 400 x 184 so it scales equally.

      Generally Outlook will honour image sizes when scaling down a larger image, but not the other way round.

      • Rombout

        Grrat thanks James, i forgot about declaration of units. It’s a habbit of me, I’m no real coder. Ps why in the example the. So add a second style, I thought that was the work around for outlook as written in the above article?

        • Not for images. It applies to layout elements like tables and table cells

          • Rombout

            Okay thanks Alain for the help!

          • Rombout

            SO it due to the unit i added that the images are scaled or do i need to add that scale syntax?
            Im not sure what i need to do

          • Would be fine. You are scaling down the original 400 x 184 image equally. In signatures however, you can’t really implement the code that needs to go in the head, as its geared towards email campaigns.

          • Rombout

            I believe inlining is the best solution, at least thats what ive been reading Some browser skip separate css. I need to do a lot more research i guess

          • Correct. Inlining CSS in general is the recommended solution. In the case of images however, you do not need to use the width and height CSS properties, you should always use the width and height attributes directly, as its better supported.

          • Rombout

            By attributes you mean style=”width:…;” right?

          • No.

            See the attributes section. You can declare a width and height on an image directly. You don’t need to use inline CSS.

          • Rombout

            okay thanks!

  • babu

    It was very helpfull unfortunately still facing font issue…fonts showing bigger can we fix this…?

  • Antonio Salcedo

    Can you please explain where is the HTML Outlook file that we need to modify with your changes?

  • Antonio Salcedo

    How does one access the Outlook Template HTML code so that I can implement the improvements mentioned here?

    I am particularly interested in solving Problem #1 above with my Outlook 2010.



  • Thanks James! Once again you save the day. Amazing post, solved my problems completely. Cheers!

  • Balázs Petróczi

    Hi! Thanks for the detailed article. It helped me solve a serious issue with rounded cornered images. I visited the link to the old Microsoft Office xml documentation, but the link to the file on that page is already obsolete. I would be grateful if someone could provide it for me.

  • Mohsin

    Any one have sample code to test on outlook. I have been facing issue of image scaling on outlook, machine[Dell xps 13] has 4K resolution which zoomed to 250% and using windows 10.

  • 2017 checking in, this works great!

  • Paul

    thanks for the great solution James! it fix the problem on outlook 2016 too.

  • Nice solution. It’s actually a problem which occurs on much higher scale on outlook. But, some information is missing. If this doesn’t works then what’s the next solution