Email testing: Litmus, Email on Acid, and the alternatives

You send a campaign. It looks perfect in your browser. Then a subscriber opens it in Outlook on Windows and sees overlapping columns. Another opens it on a Samsung Galaxy in dark mode and stares at invisible white text on a white background. Email rendering varies across 100+ client and device combinations. Testing tools exist to catch these problems before your audience does. This guide compares the main options and explains what actually matters when choosing one.

Why email testing is not optional

HTML email is not a web page. Web browsers converged on standards years ago. Email clients did not. Outlook for Windows renders HTML through Microsoft Word's engine — the same Word engine that last updated its HTML rendering around 2007. Gmail strips <style> blocks and rewrites class names. Yahoo injects its own CSS. Apple Mail handles modern CSS reasonably well but behaves differently in light versus dark mode. Samsung Mail, which accounts for roughly 7% of global email opens, renders like a separate browser altogether.

The practical result: an email that renders correctly in one client may be broken in another. Broken layout means unreadable text, misaligned images, buttons that can't be tapped, and calls to action nobody sees. Each broken render is a wasted send. The subscriber won't complain — they'll just delete.

Manual testing — sending to your own inbox, opening on your phone — covers maybe three or four clients. That leaves dozens of environments untested. Dedicated testing tools generate screenshots across 90+ clients in seconds.

What to test before every send

Visual rendering is the obvious part. A proper pre-send check goes further.

Rendering across clients. Desktop Outlook (2016, 2019, new Outlook), Gmail web, Apple Mail, iOS Mail, Samsung Mail, Thunderbird, Yahoo Mail, Outlook.com. At minimum, test the top five clients that appear in your ESP's open data. If you don't know your audience breakdown, start with Gmail web, Apple Mail mobile, Outlook desktop, and one Android client.

Dark mode. Apple Mail, Gmail Android, and Outlook mobile all apply dark mode transformations, each differently. Some invert background colors, some rewrite text colors, some do both. If you haven't tested dark mode, 40–60% of mobile users may see a version you never intended.

Links. Every link should point to the right URL. Broken links are obvious in hindsight and invisible before sending unless you check. Litmus and Email on Acid validate links automatically. For a manual workflow, click every link in a test send.

Spam scoring. Some tools run email content through spam filter heuristics. This is not a guarantee of inbox placement — real filtering depends on sender reputation, domain authentication, and subscriber engagement more than content. But catching obvious triggers (excessive capitalization, too many images, no plain text version) before sending takes two minutes and is worth it.

Accessibility. Alt text on images, sufficient color contrast, semantic heading structure, readable font sizes. Litmus includes accessibility checks. If your tool doesn't, use a standalone contrast checker and test with a screen reader manually.

Load weight. Gmail clips emails heavier than 102 KB of HTML. A clipped email shows a truncated message with a "View entire message" link that almost nobody clicks. If your HTML is over 90 KB, trim it.

Litmus

The market leader and the most complete platform. Litmus provides rendering previews across 100+ email clients, a code editor with live preview, link checking, spam testing, accessibility scoring, dark mode screenshots, and post-send analytics. The Builder tool lets you design and edit emails inside Litmus, which is useful if your team doesn't use a separate design tool.

Litmus integrates with most ESPs: Mailchimp, HubSpot, Salesforce Marketing Cloud, Brevo, Klaviyo. You can pull a draft from your ESP, test it, and push it back without leaving the platform. The email analytics module tracks opens by client, device, and read time, which helps you decide which clients to optimize for.

The downside is price. Litmus starts at $99/month for a single user with limited previews; the Plus plan at $199/month removes most limits. For a solo marketer or small team sending two campaigns per week, this may be justified — a broken send costs more in lost engagement and reputation damage than the subscription. For teams sending occasional newsletters, the price-to-value ratio is harder to defend.

Where Litmus stands out: the breadth of clients (including regional ones like Mail.ru and Yandex), dark mode testing that actually works, and the Proof feature for stakeholder approvals. If email is a primary revenue channel and your team sends daily, Litmus is the benchmark.

Email on Acid

The closest direct competitor to Litmus, with a slightly different tradeoff. Email on Acid provides rendering previews across 100+ clients, an inline code editor, link validation, spam testing, and accessibility checks. Preview quality is comparable to Litmus: screenshots are real renders, not simulations.

Pricing is lower: Basic starts at $74/month, Premium at $134/month, both with unlimited tests. That makes Email on Acid a reasonable fit for mid-sized teams that need rendering coverage but can't justify Litmus pricing.

The Campaign Precheck feature bundles rendering tests, link checks, spam scoring, and accessibility into a single pass. Upload the HTML, run Precheck, get a unified report. Operationally simpler than running each check separately.

Where it falls short: fewer ESP integrations, no built-in email editor, and analytics stop at the testing phase — no post-send tracking. If you already design in your ESP or in MJML, the missing editor isn't a problem. If you rely on post-send analytics, Litmus has the edge.

Alternatives worth considering

Mailtrap

Mailtrap started as a sandbox for transactional email testing and has grown into a broader platform. The Email Testing module captures emails sent to a fake SMTP server, so developers can inspect HTML, check spam score, validate links, and preview rendering without sending to real inboxes. This fits naturally for testing automated email flows — password resets, order confirmations, onboarding sequences — without touching real addresses. There's a free tier (100 emails/month), with paid plans from $15/month. Rendering previews are more limited than Litmus or Email on Acid, but for developer-focused workflows, the SMTP sandbox approach is hard to beat.

Parcel

A code editor built specifically for email HTML, with rendering previews across major clients, a collaborative editor, and native support for MJML and AMP. Parcel is for email developers who write code rather than marketers using drag-and-drop builders. The preview coverage is narrower than Litmus, but it handles the most common clients. If your bottleneck is building and coding emails rather than just testing them, Parcel may be more useful than a standalone testing tool.

Testi@

A newer entrant that focuses on rendering previews at a lower price point: screenshots across 90+ clients with dark mode support. No built-in editor, no spam scoring, no accessibility checks — just renders. If all you need is to confirm your email doesn't break across clients and you handle everything else in your existing workflow, the stripped-down approach keeps costs low.

Free options

If the budget is zero: send test emails to your own accounts on Gmail, Outlook.com, Yahoo, and Yandex. Open them on your phone. Toggle dark mode. This manual approach covers perhaps five clients and takes 15–20 minutes per email. Not scalable, but it catches the most common breakages. PutsMail (free, by Litmus) lets you send a test email by pasting HTML — useful for a quick check without setting up a campaign in your ESP. Neither replaces paid tools for serious volume, but both beat skipping testing entirely.

How to pick the right tool

The decision depends on three things: volume, workflow, and budget.

High volume (daily sends, multiple templates). Litmus or Email on Acid. ESP integrations and unlimited tests justify the cost. If post-send analytics matter, Litmus. If budget is tighter, Email on Acid.

Development-heavy (transactional emails, automated flows). Mailtrap. The SMTP sandbox slots into CI/CD pipelines. Developers can test emails the same way they test API endpoints: automatically, on every deploy.

Code-first teams (custom HTML, MJML). Parcel. The editor plus previews in one tool reduces context switching.

Low budget, occasional sends. Manual testing plus PutsMail for quick checks. Spend the saved money on validating your list instead — the ROI on clean data is higher than the ROI on pixel-perfect rendering in Outlook 2016.

A perfectly rendered email that lands in spam is worse than a slightly imperfect email that reaches the inbox. Testing rendering matters. Testing deliverability matters more.

Testing rendering is half the job

Litmus, Email on Acid, and their alternatives solve one problem: making sure the email looks correct when someone opens it. They do not solve the other problem: making sure the email gets delivered in the first place.

Rendering tools test what the subscriber sees. They cannot influence whether the subscriber sees anything at all. An email with perfect rendering that bounces off an invalid address produces zero value. An email sent to a spam trap damages your sender reputation regardless of how it looks. An email that reaches the Spam folder sits unread no matter how good the layout is.

This is where email validation fits in. Rendering testing and list validation are complementary steps in the same pre-send checklist. Validate the list first: remove invalid addresses, disposable emails, spam traps, and catch-all domains that inflate bounce rates. Then test rendering to confirm the email looks right in the clients your audience uses. Skip either step and you leave money on the table.

The math is straightforward. A 100,000-address campaign with 8% invalid addresses means 8,000 bounces. That spike in bounce rate damages your sender reputation, which degrades inbox placement for future sends. Over time, even subscribers with valid addresses start seeing your emails in Spam. No amount of rendering testing fixes that. Validation does.