Modern web developers take CSS for granted — until their beautiful newsletter arrives in Outlook looking like a ransom note. The reason nobody warns you about: email clients do not share a rendering engine. Apple Mail uses WebKit and handles modern CSS gracefully. Gmail strips style blocks and ignores most positioning. And desktop Outlook — still used by a huge share of business inboxes — renders HTML with Microsoft Word's engine, which means no flexbox, no grid, no background images on divs, and only a subset of CSS. The only code that survives all three is the oldest code on the web: nested tables for layout, with every style written inline on the element it affects. Our free Email Newsletter Composer generates exactly that — boring, battle-tested, 1999-style HTML — because boring is what renders identically everywhere. You write in Markdown, pick one of three templates, and copy out email-safe HTML or download it as a standalone file. This guide explains how to write a newsletter with it, the checklist every export follows, and the inbox details that decide whether anyone actually opens it.
Step one: write in Markdown. Draft your newsletter with simple Markdown — headings, bold, lists, links, images. Anyone can learn it in ten minutes, the source is plain text you can version-control and reuse, and there is no vendor lock-in or subscription. Your draft auto-saves as you type, so a closed tab costs nothing. Step two: pick a template and set the details. Choose Minimal for personal letters, Bold header for brand announcements, or Newsletter with a masthead and date line for recurring issues. Set your brand or newsletter name, write the preheader text, and pick a header colour — the live preview updates as you type, shown at the standard 600-pixel email width. Step three: copy or download. Copy the email-safe HTML into Mailchimp, ConvertKit or any sender, or download it as a standalone .html file to send via SMTP. Writing table-based email HTML by hand is miserable — a simple two-paragraph email balloons into hundreds of lines of nested tables and repeated inline styles — and the composer handles the painful part automatically: its built-in parser converts your Markdown into semantic elements, then the template engine wraps everything in email-safe tables with inline styles, 16px Arial body text with comfortable line height, properly sized headings, blockquotes with accent borders, and images constrained to the content width.
Every export from the composer follows the same five rules, and they are worth knowing because they are the rules that decide whether your email renders or breaks. Table-based layout only — no div positioning, no flexbox, no grid, because Outlook's Word engine does not understand them. All CSS inlined on elements — no style blocks, no external stylesheets, because Gmail strips them. Web-safe font stack (Arial/Helvetica) — no web fonts, because email clients cannot reliably load them. 600px max content width — the standard readable width across clients, desktop and mobile alike. Images use absolute URLs with alt text and explicit widths — email clients cannot access your hard drive, so every image needs a public https:// address, and readers with images disabled see the alt text instead of blank boxes. If those rules feel old-fashioned, that is the point: email rendering has not moved since the late nineties, and the tools that pretend otherwise are the ones whose newsletters break in Outlook.
Rendering is only half the battle — the other half is getting opened. The preheader field controls the grey preview text shown next to your subject line in the inbox; leaving it empty wastes the most valuable teaser space you have, and most senders let the first line of the email leak in instead. Keep it under about 100 characters and make it extend the subject line rather than repeat it. Images need absolute https:// URLs plus descriptive alt text, because a large share of readers have images disabled by default. And keep the total email under roughly 102KB of HTML: Gmail clips messages larger than that with a "[Message clipped]" link that kills your footer and unsubscribe link — the two things you most want a reader to reach. One more deliverability note: this tool generates the HTML, but your sender reputation — authentication (SPF, DKIM, DMARC), list hygiene, engagement — is what decides spam-folder placement. Good code gets you rendered; good practices get you seen.
Leaving the preheader empty. The inbox preview then shows the first line of your email, which is usually "Hi everyone" or a greeting — the least useful teaser you could write. Using relative image paths. An image referenced as images/photo.jpg exists only on your computer; in the reader's inbox it is a broken box. Every image needs a public absolute URL. Building with divs, flexbox or grid. They look perfect in Apple Mail and collapse in Outlook, which is where a large share of business readers live. Using web fonts. They fall back unpredictably or not at all; the Arial/Helvetica stack is the safe choice. Pasting from Word or Google Docs. Word processors inject their own markup, which email clients mangle — write in Markdown and let the composer generate clean HTML. Forgetting alt text. Readers with images disabled see nothing where your hero image should be. Skipping the test send. Every major email platform offers one; use it, and check the result in at least Outlook (desktop or web), Gmail (web and mobile app) and Apple Mail, which together cover the vast majority of inboxes. Look for images wider than the content column on mobile, links that inherited unexpected colours, and footers pushed below Gmail's clipping threshold. Send the test to yourself first, click every link, and view it with images both enabled and disabled.
The honest limits are four. First, this tool generates the HTML — it does not send the email. You paste the output into Mailchimp, ConvertKit, Substack or any SMTP service, and sending, tracking and list management happen there. Second, sender reputation is yours, not the tool's: authentication (SPF, DKIM, DMARC), list hygiene and engagement decide spam-folder placement, and no HTML generator can fix a bad reputation. Third, the Markdown parser covers the common elements — headings, bold, lists, links and images — not every exotic Markdown feature, so very fancy layouts still need hand-built HTML. Fourth, your draft auto-saves only to your own browser's localStorage, so it lives on one device unless you copy the HTML out. Within those limits, the tool does one job completely: it turns a plain-text draft into bulletproof, client-safe HTML in the time it takes to write it. A newsletter earns its click in the first line — the same skill as a video's first second. The Shorts Hook Generator produces twenty scroll-stopping openings from proven copywriting formulas; steal the structure for subject lines and nobody will mind. And if your newsletter needs a call-to-action button that survives Outlook, build one in the companion Email Button Generator, which adds the VML fallback Outlook requires. The companion guides are our freelance contract guide, for the business writing that follows a newsletter audience, our YouTube title guide, for scoring the headline before it becomes a subject line, and our invoice guide, for getting paid once the newsletter starts working.
The business writing that follows a newsletter audience — service agreement plus mutual NDA.
Score the headline before it becomes a subject line — eight factors, 0 to 100.
Getting paid once the newsletter starts working — line items, taxes and a clean PDF.