Why Does My Email Look Different in Outlook?

You design an email. It looks right in Figma. It looks right in the browser. It looks right on your phone.

Then somebody opens it in Outlook and suddenly the spacing has changed, a button looks strange, the columns don’t line up and an image that definitely had a background yesterday appears to have lost it.

If you’ve worked with HTML email for any length of time, you’ve probably met this problem. The frustrating part is that “Outlook” isn’t really one thing. Different versions of Outlook can render the same HTML email differently, which is why an email can look perfectly fine in Outlook on the web and behave completely differently in classic Outlook on Windows.

So why does it happen — and what can you actually do about it?

Why does Outlook render HTML email differently?

The short answer is that email isn’t the web.

Modern websites are designed for browser engines with broad support for HTML and CSS. Email clients have their own rendering rules, security restrictions and varying levels of CSS support.

Classic versions of Outlook for Windows are particularly well known among email developers because they use Microsoft Word’s HTML rendering engine rather than rendering email like a modern browser. That means some familiar web-design techniques simply aren’t interpreted in the way a designer or front-end developer might expect.

New Outlook and Outlook on the web behave differently again, which is why saying “It works in Outlook” isn’t actually specific enough. You need to know which Outlook you’re talking about.

Classic Outlook vs new Outlook

This distinction matters more than almost anything else when troubleshooting Outlook email rendering.

Classic Outlook for Windows has historically used Microsoft Word’s rendering engine, while new Outlook uses a more modern web-based environment. That’s why exactly the same HTML can behave differently between the two versions.

You can end up with an email that looks right in a browser preview, Apple Mail, Outlook.com and new Outlook, only for something to move when it reaches classic Outlook. That doesn’t necessarily mean the HTML is fundamentally broken. It may simply use HTML or CSS that one rendering environment understands and another doesn’t.

Understanding that difference is important because it changes the way you troubleshoot email. Rather than asking “Why doesn’t this work in Outlook?”, the better question is “Which Outlook environment is causing the problem, and what does that environment support?”

Is classic Outlook going away?

Eventually, yes. But email teams shouldn’t stop designing and testing for it yet.

Microsoft is progressively moving users from classic Outlook for Windows towards new Outlook through several stages, including opt-in, opt-out and eventually cutover. During the final stage, users will no longer be able to switch back to classic Outlook.

However, Microsoft’s current guidance says existing installations of classic Outlook through subscription and perpetual licences will continue to be supported until at least 2029. Microsoft also says administrators will receive at least 12 months’ notice before the final cutover stage is introduced.

Microsoft’s guidance on the transition to new Outlook for Windows

So although some of the Outlook-specific workarounds email developers use today may eventually become less important, we’re not there yet.

For brands and agencies, the practical question isn’t “Is classic Outlook old?” It’s “How many of our subscribers are still using it?”

If a meaningful part of your audience is opening emails in classic Outlook, it still deserves proper consideration and testing. Over time that balance will change, which is why email-client analytics and ongoing testing are more useful than designing around assumptions about what people should be using.

Why do email designers still use tables?

If you’ve come from web design, one of the stranger things about HTML email is discovering how heavily it still relies on tables.

There’s a good reason for that. Table-based layouts remain one of the most reliable ways to maintain structure across a wide range of email clients, including older and more restrictive Outlook environments. That doesn’t mean email developers are pretending it’s 2004 for fun. It means email needs to work somewhere very different from a modern website.

A web designer might naturally reach for flexible layout techniques such as Grid or Flexbox. Email developers have to think much more carefully about whether the receiving clients actually support the technique being used.

That’s why converting a web page directly into an email usually doesn’t end particularly well. Specialist HTML email development accounts for the realities of the inbox rather than assuming that browser code will behave the same way everywhere.

Common Outlook email rendering problems

There are plenty of ways Outlook can surprise you, but several problems appear repeatedly. Understanding where they come from makes them much easier to account for during email design and development.

1. Spacing looks different

Spacing that appears consistent in another email client can change in Outlook. Margins, padding, paragraph spacing and line-height can all behave differently depending on the HTML structure and Outlook environment.

The solution is often less about finding one clever CSS rule and more about building the email with predictable table structures and controlling spacing deliberately. Email development tends to reward boring reliability. If something is important to the layout, don’t assume every email client will infer it in the same way.

2. Background images disappear

Background imagery is another common source of frustration. A background image that works perfectly in many clients may not render as expected in classic Outlook for Windows.

This is one of the areas where email developers may need Outlook-specific techniques rather than relying purely on standard CSS. That doesn’t mean you can’t use background images; it means you need to design and build them with the fallback experience in mind.

Ask what happens if the image doesn’t appear. Is the text still readable? Does the email still make sense? Is there an appropriate background colour underneath it?

Resilient email design assumes that not every visual technique will survive every inbox perfectly.

3. Buttons don’t look the same

A beautifully rounded web-style CTA can become unexpectedly rectangular in a restrictive email client. Again, the mistake is assuming that buttons in email behave exactly like buttons on a website.

Email developers often use more defensive approaches to button construction so the CTA remains usable even where certain styling isn’t supported. The important questions are simple: Can I see it? Can I read it? Can I click it?

Pixel-perfect rounded corners are nice. A working call to action is more important.

4. Columns move or break

Multi-column layouts need particular care. A two-column section that looks perfectly balanced in one client can behave differently if widths, spacing or table structure aren’t interpreted as expected, and that becomes particularly important when moving between desktop and mobile versions.

Rather than designing the layout first and hoping the HTML can reproduce it everywhere, email design works better when the technical constraints are understood while the layout is being created.

It’s a recurring theme in email: design and development can’t really ignore each other.

5. Fonts change

Custom fonts are another area where email design has to accept reality. Not every email client supports every web font, so fallback fonts are an important part of the design.

If your entire layout depends on the exact width, weight and spacing of one specific typeface, a fallback can alter line breaks, button widths and the overall rhythm of the email.

That means fallback typography shouldn’t be something a developer invents at the end of the project. It should be part of the design decision from the beginning.

6. Animated GIFs can behave differently

Animation is another area worth testing rather than assuming. Where animation isn’t fully supported, the email still needs a useful static state.

That means the first frame of an animated asset matters. If the first frame contains no meaningful information because the animation was expected to reveal everything later, some recipients may miss the message entirely.

The fallback should be designed as deliberately as the animation itself.

7. Dark mode changes things again

And then, of course, there’s dark mode.

Outlook’s various environments don’t necessarily handle dark mode identically either, adding another layer to the rendering problem. Background colours, logos, typography and imagery can all be affected depending on the version being used.

We’ve covered that separately in our guide to dark mode email design, because it’s a problem big enough to deserve its own article.

Can CSS fix Outlook email problems?

Sometimes. But the answer is rarely “Just add this one CSS rule and Outlook is solved forever.”

Certain Outlook environments support techniques that others don’t, and classic Outlook may require Microsoft-specific approaches for particular effects. That can include conditional markup or MSO-specific styling aimed specifically at Outlook’s Word-based rendering behaviour.

The important thing is not to fill an email with hacks for the sake of it. Use client-specific fixes where they’re genuinely needed, keep the underlying build as clean as possible and always test the result.

A technically impressive workaround that introduces three new rendering problems hasn’t really fixed anything.

What are Outlook conditional comments?

One technique email developers can use is conditional comments. These allow certain HTML to be presented specifically to Microsoft Outlook environments while other clients receive the standard version.

The idea isn’t that every email should be covered in Outlook-specific code. Where a particular client needs a fallback or different structure, conditional approaches can sometimes provide one without compromising the experience everywhere else.

This is another reason why HTML email coding is different from standard front-end web development. You’re not just building something that looks right in one modern browser; you’re building something resilient enough to survive a fragmented collection of inboxes.

Does an email need to look identical in every inbox?

No — and trying to force it to can become counterproductive.

The goal of email QA isn’t necessarily pixel-perfect identical rendering everywhere because different clients have different capabilities. A more useful standard is whether the message is readable, the hierarchy remains clear, the brand is recognisable, the links and buttons work, important content is still present and the overall layout continues to make sense.

If Apple Mail gives you rounded corners and classic Outlook gives you square ones, that may be an acceptable compromise. If Outlook hides your main CTA, it isn’t.

This is where experience matters: knowing which differences are harmless and which ones actually damage the communication.

Figma isn’t the inbox

This is one of the biggest mindset shifts in email design.

A Figma file is a controlled environment. The inbox isn’t. In Figma, you decide exactly where everything appears. In email, you’re handing that design to Gmail, Outlook, Apple Mail and dozens of other environments and asking them to interpret HTML in their own way.

That’s why email campaign design needs to consider implementation while the creative is still being developed. A beautiful layout that requires techniques the target email clients can’t reliably reproduce isn’t necessarily a good email design.

The strongest email creative works with the medium rather than fighting against it.

How should you test emails in Outlook?

Don’t send yourself one test in whichever version of Outlook happens to be installed on your laptop and consider the job done.

Start with the Outlook environments that are relevant to your audience. Depending on the project, that might include classic Outlook for Windows, new Outlook for Windows, Outlook.com, Outlook for macOS and the Outlook apps for iOS and Android.

Then look at the areas most likely to reveal problems: layout, spacing, typography, images, backgrounds, buttons and dark mode. Are columns and widths behaving correctly? Have unexpected gaps appeared? Are fallback fonts changing the layout? Are images displaying at the intended size? Are CTAs visible and clickable?

You don’t necessarily need every inbox to be identical. You do need the important parts to work.

For larger campaigns and production workflows, specialist email testing platforms can also help preview builds across multiple clients and environments rather than relying entirely on manual tests.

Should you design around Outlook from the start?

Yes — but that doesn’t mean letting the oldest email client dictate every creative decision.

A better approach is progressive enhancement. Start with an email that remains functional in restrictive environments, then add visual improvements for clients that support them.

That way, a modern client might receive the richer visual treatment while an older Outlook environment gets a simpler version that still communicates exactly what it needs to. The experience can adapt without falling apart.

That’s much healthier than building something extremely sophisticated and then trying to reverse-engineer an Outlook version once the design has already been approved.

How Email Squad approaches Outlook email development

At Email Squad, we don’t treat Outlook testing as the awkward final step before delivery. We think about the inbox while the email is being designed.

That means identifying potentially fragile layouts early, considering fallbacks, building with real email-client support in mind and testing the finished email before it’s handed over.

Sometimes the answer is an Outlook-specific fix. Sometimes it’s a better fallback. And sometimes it’s recognising that the original design needs to change slightly if we want it to survive the environments customers actually use.

Because the objective isn’t to win an argument with Outlook. It’s to make sure the email works.

If you’ve got a Figma design that needs turning into a reliable email — or an existing build that seems to develop a personality disorder every time it’s opened in Outlook — take a look at our HTML Email Development service.