We sent a tidy 600-pixel-wide newsletter on a Wednesday. By Friday, support had a folder labeled my email looks giant. The complaints clustered on Windows, in Outlook, with no pattern across versions. The screenshots all showed the same thing: the hero, the buttons, the spacing — every dimension scaled up by what looked like exactly 50%.
Six hours and a borrowed Surface laptop later, we had it. Every complaining recipient had their Windows display scaling set to 125% or 150%. That setting — three clicks deep in Settings > Display — quietly rewrites pixel arithmetic inside Microsoft Word's HTML rendering engine, which is the engine Outlook on Windows still uses for email.
What's actually happening
When Word interprets an HTML email, it doesn't treat width="600" as 600 CSS pixels. It treats it as a physical dimension and applies the system DPI factor. On a 96 DPI display (the “100% scaling” default nobody has anymore) 600 stays 600. At 125% scaling it becomes 750. At 150% it becomes 900. Your carefully laid-out 600px email is now 900px wide and overflowing into Outlook's reading pane.
Width attributes get scaled. Height attributes get scaled. Inline style="width:600px" gets scaled. VML shapes get scaled. The one thing that doesn't get scaled is text — because text has its own DPI handling — so a hero image grows but the headline next to it doesn't. The result is the uncanny look of an email designed by two agencies who never spoke.
The fix is older than Gmail
Buried in the Office OOXML spec, there's a flag that tells Word to stop. You set it through an XML namespace declared in 1996, wrapped inside an MSO conditional comment introduced in 2007:
<!--[if gte mso 9]>
<xml>
<o:OfficeDocumentSettings xmlns:o="urn:schemas-microsoft-com:office:office">
<o:PixelsPerInch>96</o:PixelsPerInch>
</o:OfficeDocumentSettings>
</xml>
<![endif]-->The conditional limits the block to Outlook 2000 and up; every other client treats it as an HTML comment and ignores it. The OfficeDocumentSettings namespace pins Word's internal DPI to 96, which short-circuits the multiplication. Once it's in your <head>, the email stops growing.
There is no Microsoft documentation page for this fix. There is a Litmus blog post from 2016, a couple of Stack Overflow threads, and the word-of-mouth folklore of email developers. It works. Nobody seems to know why it isn't the default.
Three other things you might be debugging right now
While we're here, a quick tour of the rest of the haunted house:
- Apple Mail turns dates into calendar links. Write “Sale ends May 5” in your campaign and iOS Mail wraps “May 5” in a tappable suggestion that opens a create-event sheet. The override styling is bright blue with an underline, ignoring whatever colors you set. The lid:
<meta name="format-detection" content="date=no,telephone=no,address=no">— though some macOS Mail versions still detect through it. Apple is also extremely confident about flight numbers and package tracking codes, so “UA 219 boards at 9:15” becomes two separate suggestions. - Outlook freezes your GIF on the first frame. Animated GIFs are not animated in Outlook 2007 through 2019. You see frame zero, full stop. If your loop's payoff (“SUBSCRIBE!”) is at frame 30, Outlook recipients see a blank rectangle. Always design frame zero as the fallback.
- Yahoo Mail's mobile web view strips
<style>blocks. Anything in your<head>stylesheet vanishes; only inlinestyle="..."attributes survive. Hover rules, media queries, dark-mode overrides — all gone. Build for the lowest common denominator and inline everything.
The pattern
Every quirk above shares a shape: a feature that made sense in some other product — Word's DPI awareness, iOS's data detection, Yahoo's style sanitizer — doing its job in a context where the job is wrong. Email isn't a platform. It's twenty platforms quietly disagreeing about how to interpret HTML 4.01.
The way out is to use less HTML, not more. The smaller the surface you hand to email clients, the fewer corners they can cut in different directions. A pixel grid built from <td bgcolor="..."> cells uses no images, no fonts, no remote assets, and — crucially — almost no widths that the Word engine can multiply. The colors render on first paint, identically, on every client we've tested.
That's the technique behind picmel. Drop in a logo or a product shot, get back HTML that goes out the door without surprises. There's nothing for Outlook to scale when there are no widths to scale.