Frequently asked questions

Over 80 rules across eight areas: links, images, accessibility, email-client compatibility, Outlook, mobile, tracking (UTMs) and general HTML quality such as Gmail clipping, unsubscribe links, preheaders and leftover placeholders. Spelling is optional. Every issue shows where it is in your code, why it matters and how to fix it. The full list is on the homepage.

Yes, it's free to use, and there's no sign-up. Paste your HTML and run the check.

No. It's a fast code checker for the problems behind most rendering, accessibility and tracking bugs. Screenshot testing across email clients is a separate step — this catches the issues before you get there.

Paste the compiled HTML — run npx mjml email.mjml -o email.html first. Raw MJML is detected and you'll be asked for the output. The MJML guide covers what to look for.

Yes. Export or copy the HTML from your platform and paste it in. Merge tags like {{first_name}}, *|UNSUB|* and %%view_email_url%% are recognised and not treated as broken links.

Every email starts at 100. Each issue subtracts points by severity: critical −10, error −5, warning −2, info −1. One rule can cost at most three times its penalty, so a single repeated issue (say, 30 images missing a width) doesn't hide everything else. 90–100 is Excellent, 75–89 Good, 60–74 Needs Work and below 60 Poor.

Errors (and critical issues) are confirmed problems: an empty link, a missing alt attribute, JavaScript in the email. Warnings are things that break in some email clients or situations, such as flexbox or a background image without an Outlook fallback. Whether a warning matters depends on who you send to.

Possibly not wrong, just not relevant to your audience. Many warnings only affect certain clients — classic Outlook for Windows, for example. If your test sends look right in the clients your subscribers use, you can accept the warning.

No tool can promise that. A high score means none of the known risks we check for were found. Always send yourself a test before the real campaign.

No. The checks run entirely in your browser — the HTML you paste never leaves the page and isn't saved anywhere.

No. Links are checked by reading them, not visiting them, so tracking links, unsubscribe links and one-time links are never triggered.

Turn on Check spelling next to the Run button. It checks the text recipients read — body copy, the title and image alt text — against a US English dictionary, plus doubled words like “the the”. The dictionary downloads to your browser once; your email text still isn't sent anywhere.

It isn't in the dictionary. Click Ignore word on the finding and it won't be flagged again in your browser. Names written mid-sentence with a capital letter, and words from your own link domains, are skipped automatically.

Gmail cuts off messages whose HTML is larger than about 102 KB and shows a “View entire message” link. Anything after the cut — often the footer, unsubscribe link and open-tracking pixel — is hidden. Remove comments and unused CSS, avoid base64 images, reduce repeated inline styles and leave headroom for the tracking code your platform adds. The checker warns from about 85 KB.

Classic Outlook for Windows renders HTML with Microsoft Word, which ignores much of modern CSS: max-width, flexbox, background images, padding on links and more. The fixes are tables with explicit widths, VML backgrounds and table-cell buttons — see the Outlook guide.

Most emails use a 600–640px wide main container. It fits desktop reading panes, and with a fluid or responsive layout it scales down to phones. Avoid fixed widths above about 700px.

Tables are still the safest choice for structure because classic Outlook doesn't support modern CSS layout. A common modern approach is fluid divs with max-width for most clients, wrapped in Outlook-only “ghost tables”. Whatever you use, add role="presentation" to layout tables.

The preheader is the short preview text inbox lists show next to or below your subject line. Without one, clients show the first text they find — often “View in browser” or image alt text. Add it as hidden text at the very top of the body and keep it around 40–130 characters.

In some clients. Apple Mail, iOS Mail and some Android clients load web fonts; Gmail and classic Outlook don't. Always finish your font stack with web-safe fonts, e.g. 'Inter', Arial, Helvetica, sans-serif, and add an Outlook-only fallback so it doesn't switch to Times New Roman.

JavaScript never runs in major email clients and can send the email to spam — don't include it. Forms and <video> work in only a few clients (mostly Apple Mail). Link to a landing page instead, or use a linked image with a play button for video.

What the image communicates or where it leads: the text inside a banner, the action of an image button (“Shop the sale”), or the product shown. Use an empty alt="" for purely decorative images. The accessibility guide has examples.

Tags added to a link so your analytics tool knows where a visit came from. For email, use utm_source (e.g. newsletter), utm_medium=email and utm_campaign (the specific send) on every link, with consistent lowercase values. See the link and UTM guide.

In marketing emails, yes. Laws such as CAN-SPAM, GDPR and CASL expect an easy way to opt out, and Gmail and Yahoo require bulk senders to support one-click unsubscribe. Purely transactional emails (receipts, password resets) generally don't need one.

Some email apps invert or adjust colours in dark mode, and they don't all do it the same way. Use logos with a light outline or a version that works on dark backgrounds, avoid text baked into images, and test in Apple Mail, Gmail and Outlook with dark mode on. Apple Mail and some other clients also support @media (prefers-color-scheme: dark) for your own dark styles.

MJML is a markup language that compiles to email-safe HTML, handling responsive layouts and Outlook quirks for you. Hand-coded HTML gives full control but takes more care. Either way, the compiled HTML still needs content QA — links, alt text, tracking and copy.