Why I Still Hand-Code HTML Emails in 2025

Let’s be clear: I’m not here to romanticize old-school techniques. I’m here to explain why, even in 2025, I still hand-code HTML emails — and why that decision has saved projects, preserved brands, and protected client reputations more times than I can count.

This isn’t just a personal rant. It’s a technical walk-through, a design philosophy, and a mentor’s note to anyone frustrated by how unreliable email rendering still is. Whether you’re a designer, developer, PM, or just trying to get your campaign out the door — this is for you.

Here’s what we’ll cover:

  • Why email coding is still its own beast (hint: Outlook)
  • The limitations of WYSIWYG editors (and the hidden traps they set)
  • Table-based layouts and the quirks no one warns you about
  • Best practices that hold up across inboxes
  • How I build responsive emails that actually work

This comes from real client work. Tight deadlines. Brand-critical sends. Stakeholders who only notice when something breaks. I don’t code emails because I love the pain. I do it because I’ve learned to love the control.

It’s Not 1999 — But Email Clients Didn’t Get the Memo

Most developers assume email clients behave like browsers. They don’t. They behave like broken time machines. Microsoft Outlook, for example, still uses the Microsoft Word rendering engine. That means your markup is being interpreted like a document from 2004.

That’s why we still use nested tables. That’s why we inline styles. That’s why conditional comments still exist. It’s not elegant — but it’s reliable. And if your recipient can’t see the content? All that brand strategy and Figma polish means nothing.

Hand-Coding Gives Me Something Visual Builders Can’t

I’ve tried every drag-and-drop builder. They’re fast — until they aren’t. Until you notice extra wrappers. Broken mobile alignment. Retina images that look blurry. Layouts that shift in Gmail dark mode or Outlook desktop. Suddenly you’re in the weeds, fighting code you didn’t write.

When I write the code, I know exactly what’s happening. I optimize for load. I check rendering in Litmus and Email on Acid. I control the fallback states. I handle quirks proactively. It’s not glamorous. But it saves hours — and client trust.

Accessibility and Brand Consistency

Email should be readable — for everyone. That means semantic markup where possible. Real alt attributes. Logical reading order. Contrast that meets accessibility standards.

And when it comes to branding? I follow the style guide down to the hex, the padding, the border-radius. I use @import for fonts when supported, and web-safe fallbacks when not. It’s not overkill. It’s care.

Responsive Without Media Query Drama

Media queries are great — until you meet a client who opens emails in Yahoo Mail on desktop. That’s why I use hybrid layouts. I build tables that gracefully collapse. I plan for stacking, spacing, and tap targets. I test with real fingers, not just emulators.

If it can degrade well and still look good, it’s a win. Because not every inbox plays by the rules.

The Real Bottom Line

Hand-coding gives me control. It gives me confidence. And it protects the end experience from unpredictable rendering engines, careless generators, and untested assumptions.

If the email matters — meaning it’s tied to a sale, a campaign, a reputation — I code it by hand.

If this gave you clarity — or if you’ve been burned by a bad email send — contact me here. I’ll help you get it right the first time.