Skip to main content

Testing and preview

Before an email is exported, you usually want more than a quick in-editor check. Better Email supports several ways to preview, test, and validate email output.

In-editor preview​

The first layer is the live preview inside the Email Editor. Use it to check:

  • structure and order
  • mobile behavior
  • content length
  • image crops
  • segmented variants

This is the fastest way to spot obvious issues while you are still editing.

TODO: Add a screenshot showing desktop and mobile preview states for the same email.

Test sends​

Use test sends when you need to see the rendered email in a real inbox. This is helpful for checking subject lines, preview text, and client-specific quirks before export or launch.

Shareable previews and demos​

Depending on your workflow, Better Email can also be used to share preview links or demo versions of emails with stakeholders who do not need full editor access.

Inbox and client preview​

For deeper QA, Better Email supports inbox-based testing and multi-client preview workflows. This is where you validate how the email behaves across different desktop, web, and mobile clients.

note

Enterprise-only feature: Inbox and multi-client preview workflows are available on Enterprise plans.

This is especially important when the template uses:

  • advanced layout patterns
  • complex imagery
  • tight typography constraints
  • segmentation variants

TODO: Add a screenshot or short clip of the inbox or multi-client preview workflow.

Accessibility auditing​

Better Email also supports accessibility checks so teams can catch issues before launch. This can include checks around:

  • heading structure
  • link clarity
  • contrast
  • alt text quality

Accessibility review is easiest when it starts at the template level, but it is still valuable at the campaign level.

Best practices​

  • Use the in-editor preview early and often.
  • Always check mobile before review.
  • Test send critical campaigns.
  • Use multi-client testing for important launches or complex layouts.
  • Treat accessibility as part of QA, not a final afterthought.