Introduction
If you can build a web page, writing HTML for a newsletter sounds easy. But once you actually try, it's trickier than you'd expect. A layout that looks perfect locally breaks in Outlook, has misaligned margins in Gmail, and renders with tiny text on mobile — all at once, without warning.
The reason is simple: HTML for email plays by an entirely different set of rules than HTML for the web. This article explains why email HTML is so peculiar, and lays out the constraints you must honor to build newsletters that don't break — with AI-based generation in mind.
Why email HTML differs from the web
The thing rendering it isn't a browser
Web pages are rendered by browsers. Browsers faithfully interpret modern CSS, so we can safely use Flexbox and Grid. Email, however, is rendered by a wildly diverse set of email clients — Outlook, Gmail, Apple Mail, and countless mobile apps.
Their rendering engines are all different, and some are frozen on ancient specs. Desktop Outlook in particular renders HTML with the Word engine, so web-standard common sense simply doesn't apply. "You don't know where it'll be viewed" — that's the starting point for email HTML.
The available techniques are heavily restricted
Because environments vary so much, you can only use techniques that reliably work. Loading external CSS files is ignored by many clients, and JavaScript doesn't run at all for security reasons. Newer layout methods like position and Flexbox may or may not take effect depending on the environment.
In other words, newsletters demand the opposite value system from web development: the more "modern" your code, the more dangerous; the more "old and proven," the safer.
Build for the common denominator, not the latest
On the web you can target the latest browser, but with email you can't choose your recipient's environment. Looking the same for everyone comes first. So the design philosophy aims not for "stylish" but for "unbreakable everywhere." That compromise is what breeds email HTML's peculiar constraints.
A common failure
Build a newsletter with divs and Flexbox the way you would for the web, and it can break in half of your recipients' inboxes. Even if it looks "perfect" in your local browser, that may just mean your test environment is forgiving.
Concrete constraints for not breaking
Build the skeleton with table layouts
The single most important thing in email HTML is building layouts with nested table tags. It's a technique you'd never reach for in modern web development, but table-based columns render stably across nearly all email clients. Splitting into columns, centering a button — you express these with table cells, not divs.
It looks dated, but it's the most reliable way to "look the same everywhere."
Write every style as inline CSS
Since neither external CSS nor <style> tags can be trusted, styles are written directly on each element's style attribute. This is inline CSS. Text color, margins, font size — all written into every single element, a decidedly verbose approach.
Writing it by hand is enormous and hard to manage, but by the same token it's a job of "mechanically applying fixed rules." That's precisely what makes it worth having AI generate.
Rules for width, images, and links
Fixing the layout width at around 600px is the standard. Wider than that gets awkward on both desktop and mobile. Images can't use relative paths, so they must be specified as absolute URLs starting with https://. Rather than embedding images in the email body, you reference images hosted externally.
How to prepare for client differences
Know the tendencies of the major clients
Even while aiming for "unbreakable everywhere," knowing the quirks of the major clients helps you focus your efforts. Desktop Outlook especially is the gatekeeper — most display breakage happens there. Apple Mail, by contrast, is relatively close to web standards and renders things straightforwardly.
Individually optimizing for every client isn't realistic, so if you base your approach on "code that doesn't break in the strictest client, Outlook," the other environments mostly fall into line.
Constraints can be turned into a checklist
These constraints aren't something you honor by feel — you can spell them out into a checklist. "Am I laying out with divs?" "Is every style inline?" "Are images absolute URLs?" The items are unambiguous.
And that's the point: clear rules are easy to enforce for both humans and AI. The next article, Getting AI to Write Email HTML That Doesn't Break, explains how to fold these constraints into prompts and validate the output.
Constraints aren't the enemy
Lots of constraints feel annoying, but flip it around and it means "what you must honor is clear." The more clearly a task's rules are defined, the better it pairs with automation and AI.
Summary
Email HTML differs from the web because the thing displaying it isn't a browser, but a wildly diverse set of email clients running dated specs. That's exactly why unbreakable newsletters carry constraints like these:
- Build layouts with nested
tabletags. - Write every style as
inline CSS, directly on the element. - External CSS and JavaScript are unusable.
- Width around 600px, images as absolute URLs.
They're tedious, but because they're clear rules, they're easy for a machine to enforce. Techniques for having AI generate under these constraints are in Getting AI to Write Email HTML That Doesn't Break, and the overall system is covered in AI Newsletter Creation Overview.