HTML email has its own rules — different from web HTML, different from plain text, and different from what most guides explain. This guide covers all three creation methods, explains the technical constraints in plain language, and gives you a step-by-step workflow you can complete today.
Creating an HTML email sounds simple — it is HTML, after all, and most marketers and developers have worked with HTML before. The surprise comes quickly: an email that looks perfect in a browser breaks in Outlook, gets clipped by Gmail, or displays completely differently on mobile. These are not random bugs. They are the predictable result of a technical environment that has its own rules, its own constraints, and its own history — none of which align with modern web development.
This guide serves two audiences: marketers who want to create professional HTML emails without touching code, and developers who want to understand the specific technical constraints of email HTML before writing a single line. Both paths lead to better emails — but only once you understand why email is different from the web.
What is an HTML email — and why does it exist?
An HTML email is an email that uses HyperText Markup Language to display visual formatting: images, colors, fonts, buttons, multi-column layouts, and branded design. As opposed to a plain text email — which contains only unformatted text — an HTML email renders as a designed experience when opened in a supporting email client.
HTML emails have been the standard for marketing communications since the mid-2000s. They exist because email clients — the applications where recipients read email — learned to render HTML, giving senders control over the visual presentation of their messages. The result is that every promotional email, newsletter, or branded transactional email your audience receives is an HTML email.
The reason HTML emails require a dedicated guide in 2026 is that email clients have never converged on consistent HTML and CSS standards the way web browsers have. Writing HTML for email is not the same as writing HTML for a website — and the gap between these two worlds is larger than most people expect.
Why HTML email is different from web HTML — the constraints explained
This is the section that changes how you think about email development. Every constraint described below is the direct result of the technical reality of email clients — not arbitrary rules or outdated convention.
Outlook uses the Microsoft Word rendering engine
Windows versions of Outlook (2007 through 2021, and the transitioning new Outlook for Windows) do not use a browser engine to render HTML. They use the Microsoft Word rendering engine — the same engine that processes your .docx files. Word was never designed to render HTML, and it shows: Outlook ignores flexbox, CSS Grid, many border-radius declarations, and most CSS positioning properties. Background images require VML (Vector Markup Language), a Microsoft-specific format. Multi-column layouts require nested HTML tables, not CSS columns.
In 2026, Outlook's market share in enterprise environments remains significant. Ignoring Outlook compatibility means your emails break for a material portion of your business audience. The solution is to use table-based layouts and MSO conditional comments — both of which are explained later in this guide.
|
The Word rendering engine in plain English Imagine asking Microsoft Word to open a webpage and render it as a formatted document. That is approximately what Outlook is doing when it opens your HTML email. Word understands tables, basic inline styles, and certain image formats. It does not understand CSS positioning, flexbox, or most modern layout techniques. Design for this constraint first, then enhance for better clients. |
Gmail strips your CSS and clips large files
Gmail does not render your HTML email the way a browser does. It parses your HTML, strips the entire <head> section and any <style> tags (in some versions), sanitizes CSS class names, and rebuilds the email inside its own DOM. Practically, this means: CSS in your <style> block may be ignored in older Gmail clients. All critical styling must be inline — applied directly to each element with the style attribute.
Gmail also clips emails whose HTML code exceeds 102KB in size, replacing everything after the clipping point with a 'View entire message' link. For most emails this is not an issue — but emails with heavily nested tables, verbose inline styles, or tracking pixels embedded in the HTML can exceed this limit. Clean, minimal HTML is not just a best practice; it is a Gmail rendering requirement.
Apple Mail is the most capable — but dark mode complicates design
Apple Mail uses WebKit (Safari's rendering engine) and supports almost everything modern CSS offers: flexbox, CSS Grid, media queries, web fonts, border-radius, background images, CSS animations. An email that works in a browser will likely work in Apple Mail. The complication is dark mode: Apple Mail aggressively inverts colors in dark mode, which can make light-background emails look broken if you have not explicitly declared background colors on all elements. Light-colored text on white backgrounds becomes invisible. Transparent PNGs with dark content become unreadable.
No JavaScript — ever
JavaScript is completely unsupported in email clients, and has been for over a decade. Any interactive behavior must be achieved with CSS (limited support), AMP for Email (Gmail-only), or links that open a browser. This is not a trend or a temporary restriction — it is a permanent characteristic of the email environment driven by security concerns. If your email design requires JavaScript for any functionality, that functionality needs to be redesigned.
Tables, not divs — and why
Modern web development uses CSS-based layouts: flexbox, grid, divs with display properties. Email requires table-based layouts. This is not outdated advice — it is the current technical reality. Email clients, particularly Outlook versions using the Word engine, render table-based layouts reliably. div-based layouts break predictably in exactly the clients you cannot afford to break in.
The rule is: use <table> elements for all layout structure. Use <tr> and <td> for rows and columns. Apply styles inline on each element. This produces HTML that looks like 2005-era web development — because email rendering has not progressed the way browser rendering has.
|
Why email HTML is stuck in 2005 Web browsers update automatically and converge on modern standards because browser vendors compete on compatibility. Email clients update on different schedules, serve different use cases, and have historically prioritized security over rendering capability. Gmail strips CSS for security reasons. Outlook uses Word for rendering because it was integrated that way in 2007. The result is a rendering environment that has improved slowly while web standards have raced ahead. |
Three ways to create an HTML email — and when to use each
There are three fundamentally different approaches to creating an HTML email. Each has different skill requirements, time investments, and output characteristics. Choosing the right approach before starting saves significant time.
|
Method |
Best for / trade-offs |
|
Email builder (Stripo, Beefree) |
Best for: marketers, non-technical teams, high-volume production. Time to first email: under 30 minutes. Skill required: none. Output: professional, cross-client compatible HTML. Limitation: less custom than hand-coded. |
|
Start from a template |
Best for: users who want a starting point with some customization freedom. Time: 30–60 minutes. Skill: basic HTML helpful. Output: good. Limitation: constrained by template structure. |
|
Code from scratch |
Best for: developers building custom, pixel-perfect designs. Time: hours to days. Skill: HTML/CSS + email-specific knowledge required. Output: fully custom. Limitation: steepest learning curve. |
|
MJML framework |
Best for: developers wanting modern syntax that compiles to email-safe HTML. Time: medium. Skill: developer-level. Output: clean, reliable. Limitation: requires build toolchain. |
For most marketers and marketing teams, an email builder is the right choice — not as a compromise but as the genuine best tool for the job. A builder like Stripo handles every technical constraint described above automatically: it generates table-based layouts, inlines all CSS on export, produces Outlook-safe VML for backgrounds, and stays within Gmail's file size limits. The 1,650+ templates organized by industry mean the hardest design decision is choosing a starting point rather than building from a blank canvas.
HTML email anatomy: the structure every email needs
Whether you build with a tool or write code, understanding the structural anatomy of a correct HTML email makes you more effective with either approach. This section covers the essential elements.
The DOCTYPE declaration
Every HTML email should begin with a DOCTYPE declaration that tells the email client which version of HTML to expect. The recommended declaration for maximum email client compatibility is:
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!-- Or the simpler HTML5 DOCTYPE which also works well: --> <!DOCTYPE html> |
Most email builders handle the DOCTYPE automatically. If you are coding manually, include it — missing or incorrect DOCTYPEs can cause rendering issues in certain clients.
The preheader text — the most underused element in email
The preheader is the short text that appears in an inbox preview beneath the subject line — before the email is opened. Most marketers leave it to chance, which means the email client pulls whatever text it finds first in the email body (often 'View this email in your browser' or logo alt text).
The correct approach: add hidden preheader text immediately after the opening body tag, before any visible content. This text is hidden in the rendered email but visible in the inbox preview, giving you a second subject line.
|
<!-- Preheader text — hidden in email, visible in inbox preview --> <div style="display:none; max-height:0; overflow:hidden;"> Your 30% discount expires at midnight. Here's everything inside. </div> <!-- Buffer to prevent email client pulling in other text --> <div style="display:none; max-height:0; overflow:hidden;"> ‌ ‌ ‌ ‌ ‌ </div> |
Stripo's editor includes a dedicated preheader field in the email settings — no HTML required. Fill it in for every email. It is one of the highest-impact changes you can make to improve open rates without touching the email body.
The 600–640px width rule
HTML emails should be designed at a maximum width of 600–640 pixels. This is not a design preference — it is a practical constraint. Email client preview panes, particularly in desktop clients like Outlook and Gmail, have limited horizontal space. An email wider than 640px will require horizontal scrolling in many environments, which recipients do not tolerate.
The standard approach: set a centered wrapper table with a fixed width of 600px (or max-width of 640px for fluid designs). All content sits inside this wrapper. On mobile, the wrapper collapses to full screen width via media query or fluid percentage widths.
|
<!-- Wrapper table at 600px --> <table width="100%" cellpadding="0" cellspacing="0" border="0"> <tr> <td align="center"> <table width="600" cellpadding="0" cellspacing="0" border="0" style="max-width:600px;"> <!-- Email content here --> </table> </td> </tr> </table> |
Header, body, and footer structure
Every professional HTML email follows the same three-section structure, regardless of campaign type or visual design:
-
Header — logo, brand identity, navigation links (optional). Sets the visual context and brand recognition immediately.
-
Body — the main content: hero image, headline, body copy, product blocks, CTAs. This is where the email's job gets done.
-
Footer — unsubscribe link (legally required in most jurisdictions), contact information, physical address, social links, and preference management links.
|
The unsubscribe link is not optional CAN-SPAM (US), CASL (Canada), GDPR (EU), and most other email regulations require a visible, functional unsubscribe mechanism in every commercial email. The footer is where this lives. Email builders include unsubscribe block modules as standard. If you are coding manually, ensure your unsubscribe link uses your ESP's merge tag so it populates with a working personalized URL. |
Step-by-step: how to create an HTML email with a builder
This is the practical path for most marketers. From opening a builder to having a deployable HTML email ready for your ESP takes under 30 minutes on the first attempt and under 15 minutes with practice.
Step 1: Choose your email builder and sign up
Stripo's free tier (5 email exports per month) provides full access to the 1,650+ template library, the complete drag-and-drop editor, the HTML editor, the AI assistant, and direct export to 90+ ESPs. No credit card required. Sign up at stripo.email.
Other capable builders: Beefree (3 free exports/month, very clean interface), Tabular (Figma-like precision editing), and Unlayer (good for developers who want hybrid visual-code editing).
Step 2: Choose a starting template
Do not start from a blank canvas unless you have a specific reason to. A professional template handles the technical constraints — table structure, inline CSS, mobile responsiveness, Outlook compatibility — automatically. Your job is to customize the content, not rebuild the structure.
In Stripo, templates are organized by industry (ecommerce, SaaS, hospitality, nonprofit) and by email type (welcome, promotional, newsletter, transactional, abandoned cart). Choose the template closest to your use case and campaign type. A template that is 70% right will get you to finished faster than one that is 100% aesthetically perfect but requires structural changes.
Step 3: Customize brand identity
Before touching content, update the brand elements: logo, primary brand color, font choice, and footer contact information. In Stripo, these are typically global settings that apply to all sections simultaneously — changing the primary color updates all buttons, links, and accent elements at once.
Web-safe fonts (Arial, Helvetica, Verdana, Georgia) render consistently across all email clients. Google Fonts and custom web fonts are supported in Apple Mail and some other clients but ignored by Gmail and Outlook, which fall back to your declared font stack. For brand-consistent typography, declare your preferred font first with a web-safe fallback: font-family: 'Your Brand Font', Arial, sans-serif;
Step 4: Add and edit content
Drag content blocks onto the canvas, edit text directly in the visual editor, and replace placeholder images with your own. Key content principles:
-
Write subject line and preheader first — they determine whether the email gets opened before the design matters
-
One primary CTA per email — multiple CTAs dilute click-through rates
-
Hero image with a text headline — not an image-only hero (images are blocked by default in many clients)
-
Body copy that works without images — your email must communicate its message even when images are turned off
-
CTA button with HTML text (not image text) — image-based buttons break when images are blocked
Step 5: Preview on mobile and desktop
Before exporting, check the mobile preview. Over 60% of email opens happen on mobile devices. In Stripo, the mobile preview panel shows exactly how the email will render at mobile widths — column stacking behavior, font size scaling, button tap target sizing.
Check: does every section stack correctly on mobile? Is the font size readable without zooming? Are CTAs large enough to tap (minimum 44x44px tap target)? Is any content hidden on mobile that should be visible?
Step 6: Run a pre-send quality check
Before exporting to your ESP, run through this quick checklist:
-
Subject line and preheader filled in
-
All links tested and pointing to correct URLs
-
Alt text added to all images
-
Unsubscribe link present in footer
-
Sender name and reply-to address correct
-
Spam check passed (Stripo includes a built-in spam score checker)
-
Mobile preview checked
Step 7: Export to your ESP
In Stripo, click Export and select your ESP from the list of 90+ direct integrations. The email is pushed directly into your ESP's campaign editor — no HTML copying, no paste errors, no import reformatting. If your ESP is not in the direct integration list, use the HTML download and import it manually through your ESP's HTML import function.
The exported HTML from Stripo is clean, table-based, fully inline-CSS, and passes rendering tests across all major clients including Outlook 2007–2021. No post-export fixes required.
How to code an HTML email from scratch
For developers who want full control, this section covers the specific technical requirements of hand-coded HTML email. Web development experience helps — but email HTML has its own rules that override web conventions.
The basic document structure
A minimal HTML email document looks like this:
|
<!DOCTYPE html> <html lang="en" xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <title>Email subject line here</title> <!--[if mso]> <noscript> <xml><o:OfficeDocumentSettings> <o:PixelsPerInch>96</o:PixelsPerInch> </o:OfficeDocumentSettings></xml> </noscript> <![endif]--> </head> <body style="margin:0; padding:0; background-color:#f4f4f4;"> <!-- Preheader --> <!-- Wrapper table --> <!-- Email content --> </body> </html> |
The xmlns declarations for VML are required for Outlook background image support. The MSO conditional comment with PixelsPerInch prevents DPI scaling issues in high-resolution Outlook environments.
MSO conditional comments for Outlook
MSO conditional comments are HTML comments that only Outlook reads. They allow you to target Outlook-specific code without affecting other clients. The most common use case is providing Outlook-specific column widths and table structures.
|
<!-- Outlook sees this, other clients ignore it --> <!--[if mso]> <table width="600" cellpadding="0" cellspacing="0"> <tr><td width="300"> <![endif]--> <!-- All clients see this --> <div style="display:inline-block; width:300px;"> Column content here </div> <!--[if mso]> </td></tr> </table> <![endif]--> |
This 'ghost table' pattern allows modern clients to use div-based layouts while Outlook sees a table structure. It is the standard technique for multi-column email layouts that need to work across all clients.
Inline CSS — the non-negotiable rule
All critical styling must be inline. Gmail strips <style> tags. Outlook ignores many class-based styles. The only styling that works reliably in all clients is inline style attributes on each element.
|
<!-- Wrong — may be stripped by Gmail --> <style>.button { background: #2D3FBF; color: white; }</style> <a class="button">Click here</a> <!-- Correct — inline style survives all clients --> <a href="https://example.com" style="background-color:#2D3FBF; color:#ffffff; padding:12px 24px; text-decoration:none; display:inline-block; font-family:Arial,sans-serif; font-size:16px;"> Click here </a> |
Writing inline CSS manually is verbose and error-prone. Email builders handle this automatically on export. If you are coding manually, use an inline CSS tool (such as Juice or inline-css) to convert stylesheet rules to inline styles before testing.
Mobile responsiveness with media queries
Media queries for email are supported by Apple Mail, Gmail on mobile (iOS and Android), and most modern mobile clients — but not by Gmail on desktop or Outlook. This means media queries should be progressive enhancements: design the email to work at 600px fixed width first, then use media queries to improve the mobile experience.
|
<style type="text/css"> @media only screen and (max-width: 600px) { .container { width: 100% !important; } .column { display: block !important; width: 100% !important; } .hide-mobile { display: none !important; } .text-center { text-align: center !important; } h1 { font-size: 24px !important; } } </style> |
Note the !important declarations — these are required to override inline styles, which have higher CSS specificity than stylesheet rules. This is the standard pattern for email responsive overrides.
Cross-client compatibility: the essential rules
These are the specific rules that determine whether your email renders correctly across Gmail, Outlook, Apple Mail, and mobile clients.
|
Rule |
Why it matters |
|
Keep HTML under 100KB |
Gmail clips at 102KB — everything after the clip is hidden including your unsubscribe link. Strip comments, compress images, remove unused markup. |
|
Use tables for layout |
Outlook requires table-based layouts. CSS positioning, flexbox, and grid break in Outlook environments. |
|
Inline all critical CSS |
Gmail strips <style> tags in some clients. All styling that must appear correctly needs inline style attributes. |
|
Set explicit image dimensions |
Without width and height attributes, images cause layout reflow that looks broken while loading and with images disabled. |
|
Always include alt text |
Many clients block images by default. Alt text is what your email communicates when images are off. |
|
Use web-safe font stacks |
Custom fonts are ignored by Gmail and Outlook. Always declare a web-safe fallback: font-family: 'Custom', Arial, sans-serif. |
|
Declare background colors explicitly |
Apple Mail dark mode inverts colors. Explicit background-color declarations on all elements prevent unintended inversions. |
|
Test before every send |
Every email client behaves differently. Use Litmus, Email on Acid, or Stripo's built-in preview tool before deployment. |
Design principles for HTML email
Good HTML email design is not the same as good web design. The constraints are different, the viewing context is different, and the goal is different.
Mobile-first is mandatory
Over 60% of email opens happen on mobile devices. Design for mobile first — single-column layouts, minimum 16px body font size, minimum 44px tap targets for buttons, adequate white space between tappable elements. Then enhance for desktop. An email that works perfectly on desktop but breaks on mobile fails for the majority of its audience.
Design for images off
Many email clients block images by default, and many recipients never enable them. Your email must communicate its core message — and especially its call to action — without images. This means: every image has descriptive alt text, your hero section includes a text headline (not just an image), and your CTA button uses HTML text rather than an image-based button.
A simple test: disable images in your email preview and read the result. If the email still communicates its purpose clearly, you have designed it correctly.
One primary CTA per email
Multiple calls to action dilute each other. A recipient who sees three equally prominent buttons is less likely to click any of them than a recipient who sees one clear, prominent CTA. Every other link in the email should be visually subordinate to the primary CTA. Use button styling for the primary CTA. Use text links for secondary actions.
Typography: font stacks and safe sizes
Web-safe font stacks ensure your typography renders consistently regardless of which client displays the email. Recommended stacks:
-
Sans-serif: Arial, Helvetica Neue, Helvetica, sans-serif
-
Serif: Georgia, Times New Roman, Times, serif
-
Minimum body font size: 16px on mobile (14px on desktop acceptable)
-
Minimum line height: 1.5 (150%) for body text
-
Maximum line length: 60–70 characters per line for readability
Deliverability: how HTML quality affects inbox placement
HTML email quality directly influences whether your email reaches the inbox or the spam folder. Spam filters analyze the code of your email alongside its content and sender reputation.
HTML signals that trigger spam filters
-
JavaScript — no legitimate email needs JavaScript, so its presence signals spam
-
Hidden text (white text on white background, zero-opacity text) — a classic spam technique
-
Excessive image-to-text ratio — emails that are 90% images and 10% text look like spam
-
Broken HTML — malformed tags, unclosed elements, and invalid structure trigger spam heuristics
-
Excessive links — many links relative to content volume is a spam signal
-
No plain text version — email platforms require a plain text alternative alongside HTML
The text-to-image ratio rule
The recommended text-to-image ratio for marketing emails is at least 60% text, 40% images. Image-heavy emails — even with legitimate content — are more likely to be filtered as spam because image-only emails have historically been used to hide spam content from text-based filters. The practical implication: every image section should have accompanying visible text.
File size discipline
Keep your HTML under 100KB. This is both a deliverability best practice and a Gmail clipping requirement. Common sources of file size bloat: over-inline of CSS (tools that inline every possible property rather than just critical ones), large base64-encoded images embedded in the HTML (instead of hosted externally), and verbose template scaffolding that does not need to be in the final exported file. Email builders like Stripo produce clean, minimal HTML that stays well within this limit.
Email accessibility: designing for all recipients
Email accessibility is the most underserved topic in most HTML email guides. Approximately 1 in 12 people has some form of color vision deficiency. Screen readers are used by millions of email recipients. Accessible emails reach more of your audience more effectively.
Alt text for all images
Every image in your email needs a descriptive alt attribute. Alt text serves two purposes: it displays when images are blocked, providing context for what the image contained; and it is read aloud by screen readers, describing the visual content to recipients who cannot see it.
Alt text should describe the content and function of the image. For a product image: 'Black leather messenger bag, front view.' For a promotional banner: '30% off summer sale — ends Sunday.' For decorative images that add no content: use an empty alt attribute (alt="") so screen readers skip them.
Color contrast requirements
Text must have sufficient contrast against its background to be readable by people with visual impairments. The WCAG (Web Content Accessibility Guidelines) standard for normal text is a contrast ratio of at least 4.5:1. Dark text on light backgrounds and light text on dark backgrounds both work — as long as the contrast ratio is sufficient. Pure black (#000000) on pure white (#ffffff) achieves a 21:1 ratio. Medium gray (#888888) on white achieves only 3.5:1 — below the WCAG standard.
Semantic structure for screen readers
Use semantic HTML elements where email clients support them: <h1>, <h2>, <p>, <ul>, <li> provide structural meaning that screen readers use to navigate. Always declare the document language in the html tag (lang="en") so screen readers use the correct pronunciation rules. Avoid putting important content exclusively in images — screen readers cannot read image-based text.
Frequently asked questions
Do I need to know HTML to create an HTML email?
No. An HTML email is any email that uses HTML for formatting — but you do not need to write the HTML yourself. Email builders like Stripo generate the HTML automatically from your visual design. You drag content blocks, edit text, choose colors and fonts, and the builder produces correctly structured, cross-client compatible HTML on export. Most professional marketers create HTML emails without writing a single line of code. Understanding what HTML email is and why it behaves differently from web HTML is useful context — but it is not a prerequisite for creating effective email campaigns.
Why does my email look different in Outlook than in Gmail?
Because Outlook and Gmail use completely different rendering engines. Gmail renders HTML inside its own sanitized DOM and strips some CSS. Outlook desktop versions use Microsoft Word's rendering engine, which was never designed for modern CSS and ignores properties like flexbox, CSS Grid, and most CSS positioning. Apple Mail uses WebKit and is the most standards-compliant. The result is that the same HTML code will render differently in each client. The solution is to design with the constraints of all major clients in mind from the start — using table-based layouts, inline CSS, MSO conditional comments for Outlook, and testing in each major client before sending.
What is the Gmail 102KB limit and how do I avoid it?
Gmail clips HTML emails whose code size exceeds approximately 102KB, replacing everything after the clipping point with a 'View entire message' link. This hides your footer, unsubscribe link, and any content after the clip — including legally required elements. To stay under the limit: use an email builder that generates clean, minimal HTML (Stripo's exports are well within the limit); host all images externally rather than embedding them as base64 in the HTML; remove HTML comments and whitespace from the final output; and avoid redundant inline CSS declarations. Check your email's file size before sending using your builder's preview tool or by inspecting the exported HTML.
What is an HTML email template and should I use one?
An HTML email template is a pre-built email design — a complete HTML structure with placeholder content — that you customize with your brand and message. Using a template is the fastest and safest way to create professional HTML emails because the template has already solved the technical challenges: table-based layout, Outlook compatibility, mobile responsiveness, and cross-client rendering. Starting from a template rather than a blank canvas removes hours of technical work. Stripo's library of 1,650+ templates covers every industry and email type. Choose the template closest to your use case, update the brand elements and content, and export.
How do I test my HTML email before sending?
Test at three levels before any send. First: visual preview in your builder's mobile and desktop preview pane — check for obvious layout issues and content errors. Second: cross-client rendering test using Litmus, Email on Acid, or Stripo's built-in testing tool — preview the email in 50+ clients including all Outlook versions, Gmail, Apple Mail, and major mobile clients. Third: send a test email to real inboxes you control — your own Gmail, Outlook, and Apple Mail addresses. Never send to your full list without completing all three levels. A single broken Outlook render reaching tens of thousands of recipients is a reputational and deliverability problem that far outweighs the time investment of testing.
What is MJML and when should I use it?
MJML is an open-source email markup language designed specifically for email development. You write in MJML's simplified, human-readable syntax and it compiles to correct email HTML — handling table structure, inline CSS, Outlook MSO conditionals, and mobile responsiveness automatically. MJML is appropriate for developers who want the productivity of a modern markup language without the repetitive boilerplate of hand-coded email HTML. It requires a build step (Node.js command line or an online compiler) and has no visual editor — it is entirely code-based. For non-developers, Stripo's dual visual-and-HTML editor is a better fit: it provides the same clean HTML output as MJML without requiring a build toolchain.
Final thoughts
Creating an HTML email is a different skill from creating a webpage — but it is not a harder skill. The constraints are specific and learnable. Once you understand why Outlook requires table layouts and why Gmail clips large files, the rules stop feeling arbitrary and start feeling logical.
For most marketers, the right path is an email builder: choose a template, customize the content and brand, preview across devices, and export to your ESP. Done correctly, this produces better HTML than most hand-coded emails — because the builder has already solved the cross-client compatibility problems that trip up developers who are new to email.
For developers, the investment in understanding email-specific HTML — table layouts, inline CSS, MSO conditional comments, media query patterns — pays off quickly. Email campaigns move fast, and a developer who can produce Outlook-safe templates without debugging cycles is significantly more productive than one discovering these constraints mid-campaign.
Either path starts the same way: open a builder or a text editor, and build one email. The experience of that first complete send teaches more than any guide can.
