You cannot fix a rendering bug you have not seen. That is the whole problem with Outlook: the email passes in your browser, passes in your ESP preview, passes in Gmail, and then lands in a corporate inbox looking like a ransom note. Testing is the step that closes that gap, and most of it costs nothing.
This is the practical method. Which Outlook versions actually matter, a free three-tier test ladder, what to look for in a render, and the point where a paid rendering service starts earning its money.
The Fast Answer: How to Test HTML Email in Outlook
Test in this order, and stop as soon as something breaks:
- Check the code structurally before you render anything, so you catch the known failure patterns as text rather than hunting them in a screenshot.
- Open the email in a real classic Outlook desktop client on Windows, because that is the only engine that produces the bugs people mean by Outlook rendering issues.
- Send a real proof through the ESP you will actually send from, since the file you uploaded is not always the HTML that reaches the inbox.
- Read that proof twice, once with images blocked and once on a 120 DPI display.
The one thing that ruins an Outlook test is testing the wrong Outlook. If you check Outlook.com in a browser and call it done, you have tested a browser engine and learned nothing about the engine that breaks things.
Which Outlook Versions You Actually Need to Test
Outlook is not one client, and the difference is not cosmetic. It is two different rendering engines wearing the same name.
The Word engine family. Outlook 2007, 2010, 2013, 2016, 2019 and classic Microsoft 365 desktop Outlook on Windows all render HTML with the Microsoft Word engine. This is where rounded buttons flatten, background images vanish, and stacked padding pushes a row past 600px. If you test one thing, test this.
The browser-engine family. Outlook for Mac, Outlook.com, the iOS and Android apps, and New Outlook for Windows all use browser-style rendering. They behave close enough to a modern client that an email which survives the Word engine will almost always survive them.
That split is why version-by-version testing is mostly wasted effort. Group by engine, not by year: one classic Windows desktop render, one browser-engine render, done. The full breakdown of why the Word engine breaks email covers what each limitation does to a layout.
The awkward part is honest to state: reproducing the Word engine requires Windows and a classic Outlook desktop install. There is no browser-based shortcut, because the bug you are chasing does not exist in a browser. If you do not have a Windows machine, the realistic options are a colleague’s, a cheap Windows VM, or a paid rendering service that runs the render for you.
The Free Test Ladder: Three Tiers, No Subscription
Tier one: read the code, not the render
Most Outlook damage is visible in the HTML before anything is rendered, and it is faster to spot as text. Walk the widest row and confirm the padding, column widths and gutters total 600px or less. Confirm every <img> has a pixel width attribute. Confirm image-only cells carry line-height:0; font-size:0;. Confirm each standalone button has an [if mso] branch.
Our free HTML Email Tester runs that pass in the browser, including the Outlook width check, and returns a report without an upload or an account. It is the cheapest tier because it needs no client at all.
Do the same for dark mode while you are here. Outlook’s forced recoloring is a separate failure mode from the Word engine, and the Dark Mode Email Tester shows both states side by side.
Tier two: render in a real classic Outlook
Get the HTML into a classic Windows desktop Outlook and look at it. Two reliable ways in:
- Send it to yourself. Any account that classic Outlook can read works. This is the closest thing to a real send.
- Open the file directly. Save the HTML and open it in Outlook as a message, which is faster for iterating on a template you are still building.
Then read the render with intent. You are not admiring it, you are checking six specific things, listed in the next section.
Tier three: send a real ESP proof
This tier catches what neither of the others can. ESPs rewrite links for click tracking, inject open pixels, add footers, and in some cases restructure parts of the HTML. The template you tested is not always the email that ships.
So send the campaign to yourself from the platform you will actually send from, and test that message. A pre-send QA pass covers the rest of what belongs in this proof, including link and unsubscribe checks that have nothing to do with rendering.
What to Look For in an Outlook Render
Read every Outlook render against the same six checks. They map directly to the six ways the Word engine breaks a layout.
| Check | What failure looks like |
|---|---|
| Row width | The layout widens, a column drops below its neighbor, or the right edge is cut off |
| Image sizing | An image renders at native size and forces the container wider than the rest of the email |
| Phantom gaps | A thin white line sits under a logo, banner or hero image that should be flush |
| Button shape | A rounded CTA renders as a hard-edged rectangle, or only the label is clickable |
| Background art | A hero keeps its text but loses its background image entirely |
| Long tokens | A URL, order ID or legal identifier stretches its cell and drags the layout with it |
Then read it twice more. Once with images blocked, because Outlook can suppress remote images until the reader allows them and alt text becomes the entire email. Once at 120 DPI on a Windows display, where Outlook’s scaling can widen fixed-width elements that looked correct at 96 DPI.
Two things are worth checking on the browser-engine side too, since they fail there rather than in Word: dark-mode recoloring on your logo, and any button that relies on live text rather than an image.
When a Paid Rendering Service Earns Its Keep
The free ladder finds structural breaks. A paid service like Litmus or Email on Acid finds them faster and across more clients at once, which matters in three situations: you send weekly rather than monthly, your list is corporate enough that classic Outlook is a large share of opens, or you need a screenshot record for a client or a stakeholder.
For a solo operator sending a few campaigns a month, the ladder above is enough. The cost of the subscription is better spent elsewhere until Outlook is a meaningful part of your audience. Outlook accounts for a relatively small share of total opens overall, but that share concentrates hard in corporate inboxes, which is exactly where a broken render is least forgivable.
Test Less by Building Outlook-Safe From the Start
Testing is a detection system. It tells you something broke, after it broke. The cheaper move is to stop producing the breaks.
Every check in this piece traces back to a rule that could have been applied at build time: padding once per row, an explicit width on every image, zeroed line-height on image-only cells, a VML branch on every standalone button, word-break on long-copy cells. None of them are hard. They are just easy to forget on the fourth email of the week.
That is the design behind EmailTemple. Those rules are baked into the architect prompt and confirmed by a server-side layout check, so the exported HTML is Outlook-safe by construction rather than by cleanup. You still test — you should always test — but the render stops being the place you discover problems. Generate a template for free and put it through the ladder above.
Frequently Asked Questions
Can I test HTML email in Outlook without paying for Litmus or Email on Acid?
Yes. The free three-tier ladder covers most of what a paid service would tell you: check the code structurally, open the email in a real classic Outlook desktop client, then send a real proof through your ESP.
Paid services are worth it when you send often, send to corporate lists, or need a screenshot record across many client versions at once. For a handful of sends a month, the free ladder catches the same structural breaks.
Does testing in Outlook.com or the Outlook web app count?
Not for the bugs people mean by Outlook rendering issues. Outlook.com, Outlook for Mac, the mobile apps and New Outlook for Windows all use browser-style rendering engines, so an email can pass in every one of them and still break in classic Outlook desktop on Windows.
Those clients are worth a look. They do not substitute for a classic desktop render, because they do not use the Word engine.
Which Outlook version should I test first?
Test classic Outlook desktop on Windows first. Outlook 2007 through 2019 and classic Microsoft 365 desktop Outlook all use the Word rendering engine and fail in broadly the same ways, so one classic desktop render catches most of the damage.
If that render is clean, the browser-engine Outlook clients are very unlikely to surprise you.
How do I test what my email looks like with images blocked?
Turn off automatic image downloads in Outlook, under File then Options then Trust Center, and open the email again. Every image becomes its alt text.
If the email stops making sense, the message is living inside an image rather than in the HTML. That is a structural problem, not a rendering one, and no amount of testing fixes it.
Do I need to test every Outlook version separately?
No. Group them by rendering engine instead of by version number. One classic Windows desktop render covers the Word engine family, and one browser-engine client covers New Outlook, Outlook.com and Outlook for Mac.
The exception is high-DPI scaling. A 120 DPI Windows display can widen fixed-width elements in ways a standard display will not show you.
Why does my email look right in my ESP preview but wrong in Outlook?
ESP previews render in a browser, so they show you what a browser engine does with your HTML, not what the Word engine does. A preview cannot reproduce missing border-radius, dropped background images, or the row-padding overflow that widens a layout in classic Outlook.
Treat the ESP preview as a content check, and a real Outlook render as the rendering check. They answer different questions.
