Generate Email Preview Screenshots with an API
You build an email template, tweak the padding, adjust the hero image, and then comes the question: does it actually look right in someone's inbox? Every email client renders HTML its own way, and the only reliable answer is a visual preview. Most teams either eyeball test emails on their own phones or pay for dedicated testing platforms that cost hundreds per month. An email preview screenshot API offers a lighter path: pass your template HTML, pick a viewport width, get back a pixel-accurate image. No platform to log into, no test emails to send.
Why Email Preview Testing Is Still Painful
Every email client renders HTML differently, and the differences are maddening. Outlook uses Microsoft Word's rendering engine, which means half the CSS spec doesn't exist. Gmail strips <style> blocks entirely and only respects inline styles. Apple Mail handles modern CSS well but aggressively inverts colors in dark mode, making logos vanish against dark backgrounds.
Most teams deal with this by sending test emails to a handful of personal accounts and eyeballing them on their phones. This catches the obvious problems. It misses the subtle ones: a button that looks fine on an iPhone but clips its text on a Galaxy S24, a two-column layout that stacks incorrectly at 320px, an image that gets blocked by default in Outlook and leaves a gaping white hole. Getting an email client rendering screenshot from each environment manually is slow and incomplete.
Dedicated testing platforms like Litmus solve this by sending your email to 90+ real clients and capturing screenshots from actual inboxes. The results are accurate. The price is not: $500 per month for their base plan, with no cheaper option. Email on Acid offered a $99 tier, but Mailgun is transitioning it to "Mailgun Inspect" and the future pricing is unclear. For a team that sends a weekly newsletter and a few transactional emails, paying $6,000 a year for rendering previews is hard to justify. A Litmus alternative API that handles development-stage previews at a lower cost makes more sense for most teams.
Where an Email Preview Screenshot API Fits
A screenshot API renders your email HTML in Chromium and returns an image. It does not simulate Outlook's Word engine or Gmail's CSS stripping. That distinction matters, and we'll be upfront about it.
What it does cover: layout verification, responsive behavior, dark mode rendering, and image placement. As an html email preview api, it handles the development loop where Chromium rendering catches the majority of issues. Write the template, preview it, fix problems, repeat. Teams that need final pre-send verification across all real clients can still use Litmus for that last check, but they no longer need it for every iteration during development.
The practical split looks like this: use the screenshot API for daily development and QA (cheap, fast, automated). Reserve the dedicated testing platform for the final sign-off before a major campaign launch. You preview email before sending through the API, and save the full client matrix for launch day. Your monthly cost drops from $500 to $9 plus a few Litmus runs per month.
Rendering Email HTML Without Hosting It
Most email templates live in code, not on a URL. They sit inside your codebase as Handlebars files, React Email components, MJML source, or raw HTML strings assembled by your email service provider. Traditional screenshot tools need a URL to capture. Your email template doesn't have one.
The html parameter solves this. Pass your raw email HTML directly to the API, and it renders the markup in a headless browser and returns a screenshot. No staging server, no temporary hosting, no sending a test email to yourself and screenshotting your inbox. The HTML to image feature handles the rendering exactly as if the HTML were a hosted page.
curl -X POST "https://api.screenshotrun.com/v1/screenshots/capture" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"html": "<!DOCTYPE html><html><body style=\"margin:0;padding:0;background:#f4f4f4\"><table width=\"600\" cellpadding=\"0\" cellspacing=\"0\" style=\"margin:0 auto;background:#ffffff\"><tr><td style=\"padding:40px 30px;font-family:Arial,sans-serif\"><h1 style=\"color:#333\">Welcome aboard</h1><p style=\"color:#666;line-height:1.6\">Thanks for signing up. Here is what happens next.</p><a href=\"#\" style=\"display:inline-block;padding:12px 24px;background:#0066cc;color:#fff;text-decoration:none;border-radius:4px\">Get Started</a></td></tr></table></body></html>",
"width": 600,
"format": "png"
}' \
-o email-preview.pngSet width=600 because that's the standard email body width. For a mobile preview, drop it to 320 or 375. Two API calls, two screenshots, and you have a desktop-mobile pair to compare.
Testing Responsive Email Layouts Across Breakpoints
Email width is not one-size-fits-all. A template that looks perfect at 600px might collapse awkwardly at 480px on a smaller tablet, or lose its two-column layout at 375px on a phone. The only way to verify responsive behavior is to render the same template at multiple widths and visually compare the results.
The standard breakpoints for email testing are 320px (small phones), 375px (iPhone), 414px (larger Android phones), 480px (phablets), and 600px (desktop email standard). With a screenshot API for email templates, you can loop through all five widths in a single script and get a complete responsive audit in seconds. This is the same workflow developers use for web responsive testing via custom viewport, adapted for the narrower constraints of email.
Look at the resulting screenshots in order from narrowest to widest. Common problems that show up: text that overflows its container at 320px, buttons that become too small to tap at narrow widths, images that don't scale down and create horizontal scrolling, and hero sections that leave awkward white space at intermediate widths. Catching these in development is far cheaper than fielding support emails from subscribers complaining about broken formatting.
Testing Dark Mode Email Rendering
Dark mode breaks email designs in ways that are hard to predict. Over 80% of Apple Mail users have dark mode enabled. Gmail on Android inverts colors using its own algorithm, ignoring your CSS entirely. Logos with transparent backgrounds disappear. Brand colors shift. Dark text on a white card becomes unreadable white text on a dark card.
The dark mode parameter captures your email template with Chromium's dark mode active. This simulates how clients that respect prefers-color-scheme: dark will render your email. Generate both variants with two API calls and compare them side by side. You can also inject custom dark mode CSS through the css parameter to test how your @media (prefers-color-scheme: dark) overrides actually look before deploying them.
A Node.js script that produces desktop and mobile previews in both light and dark mode for a batch of email templates:
const fs = require('fs');
const path = require('path');
const API_KEY = process.env.SCREENSHOTRUN_API_KEY;
const TEMPLATE_DIR = './email-templates';
const viewports = [
{ name: 'desktop', width: 600 },
{ name: 'mobile', width: 375 },
];
const modes = [
{ name: 'light', dark_mode: false },
{ name: 'dark', dark_mode: true },
];
async function captureTemplate(templateFile) {
const html = fs.readFileSync(path.join(TEMPLATE_DIR, templateFile), 'utf-8');
const slug = path.basename(templateFile, '.html');
for (const viewport of viewports) {
for (const mode of modes) {
const response = await fetch(
'https://api.screenshotrun.com/v1/screenshots/capture',
{
method: 'POST',
headers: {
'Authorization': `Bearer ${API_KEY}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
html,
width: viewport.width,
dark_mode: mode.dark_mode,
format: 'png',
}),
}
);
const dir = path.join('previews', slug);
fs.mkdirSync(dir, { recursive: true });
const fileName = `${viewport.name}-${mode.name}.png`;
const buffer = Buffer.from(await response.arrayBuffer());
fs.writeFileSync(path.join(dir, fileName), buffer);
console.log(`${slug}: ${fileName}`);
}
}
}
async function run() {
const templates = fs.readdirSync(TEMPLATE_DIR).filter(f => f.endsWith('.html'));
for (const tpl of templates) {
await captureTemplate(tpl);
}
console.log('All previews generated in ./previews/');
}
run();After running this on a directory of 15 email templates, you end up with 60 screenshots (15 templates times 4 variants). Open the dark variants and scan for vanishing logos, illegible text, or color inversions. Fixing these before sending saves your brand from looking broken in the inbox of every iPhone user.
Automating Email Template QA in CI/CD
Transactional emails change with the product. A new pricing tier means updating the invoice template. A rebranding means new colors across every template. If you're a SaaS product with 15 transactional email templates (welcome, invoice, password reset, shipping notification, trial expiration, etc.), each one needs to render correctly after every change.
Adding an email rendering test api call to your CI/CD pipeline catches regressions at the pull request stage. The workflow: render each template's HTML through the API at desktop and mobile widths, save the screenshots as artifacts, compare against baseline images from the main branch. If a template changed visually, the diff shows up in the PR review. This lets you automate email preview testing instead of relying on someone to eyeball every template manually.
For teams using GitHub Actions, this fits into an existing test step. For Jenkins or GitLab CI, the same script runs as a post-build task. The API call takes under 5 seconds per screenshot, so a full matrix of 15 templates at 2 viewports completes in about a minute. The visual regression testing guide covers the pixel-diff comparison technique in detail. For teams already running website change monitoring, the same comparison logic applies to email templates.
Same workflow in Python:
import requests
import os
import json
API_KEY = os.environ['SCREENSHOTRUN_API_KEY']
TEMPLATE_DIR = './email-templates'
viewports = [
{'name': 'desktop', 'width': 600},
{'name': 'mobile', 'width': 375},
]
for tpl_file in os.listdir(TEMPLATE_DIR):
if not tpl_file.endswith('.html'):
continue
slug = tpl_file.replace('.html', '')
html = open(os.path.join(TEMPLATE_DIR, tpl_file)).read()
for vp in viewports:
response = requests.post(
'https://api.screenshotrun.com/v1/screenshots/capture',
headers={'Authorization': f'Bearer {API_KEY}'},
json={
'html': html,
'width': vp['width'],
'format': 'png',
}
)
folder = os.path.join('previews', slug)
os.makedirs(folder, exist_ok=True)
filepath = os.path.join(folder, f'{vp["name"]}.png')
with open(filepath, 'wb') as f:
f.write(response.content)
print(f'{slug}: {vp["name"]}.png')
print('All previews generated.')Generating Thumbnails for Email Template Libraries
SaaS products that offer email template builders (Mailchimp, SendGrid, custom-built) need thumbnail previews for the template picker. Users browse a grid of templates and choose one. Those thumbnails need to look accurate, update automatically when templates change, and load fast.
A screenshot API for email templates generates these thumbnails programmatically. Pass each template's HTML to the API at a width of 600, then use the resize_width parameter to shrink the result to thumbnail dimensions for the picker grid. The image format feature lets you choose WebP for small file sizes or PNG for maximum clarity. For template marketplaces with hundreds of designs, use webhook_url to process the batch asynchronously.
This also works for approval workflows in email agencies. Instead of giving every client a Litmus login or forwarding test emails that land in spam, generate PNG previews at desktop and mobile widths and drop them into a shared folder. Clients see exactly what subscribers will see. No account needed, no forwarded test emails.
A/B test variants deserve the same treatment. When your marketing team creates two subject line versions or two hero image options, generate email template screenshots of each variant at both viewport widths. Four screenshots per A/B test give every stakeholder a clear picture of what subscribers will see, without needing access to the ESP.
Screenshot API vs Dedicated Email Testing Platforms
| Factor | Screenshot API (ScreenshotRun) | Litmus / Email on Acid |
|---|---|---|
| What it renders | Chromium browser engine | 90+ real email clients (Gmail, Outlook, Apple Mail, etc.) |
| Dark mode | Chromium simulation via dark_mode | Real dark mode from each client |
| Monthly cost | $9/mo (Starter plan, 2,000 screenshots) | $500+ (Litmus), $86+ (Email on Acid) |
| HTML input | html parameter, no hosting needed | Upload or send test email |
| API response time | Under 5 seconds | 30-120 seconds for full client matrix |
| CI/CD fit | Single HTTP call per screenshot | Possible but heavier integration |
| Viewport control | Exact pixel width via custom viewport | Preset device list |
| Best for | Development QA, thumbnails, visual regression, approvals | Final pre-send verification across all real clients |
| Limitation | Cannot replicate Outlook Word engine or Gmail CSS stripping | Expensive, slower, overkill for dev iteration |
The honest take: a screenshot API handles the development loop cheaply and fast. Dedicated platforms handle final pre-send verification accurately. Many teams use both. The screenshot API covers daily iteration at $9 per month. The dedicated tool comes out for the quarterly campaign launch. Your annual spend drops from $6,000 to around $200.
Email Preview Screenshot API Parameters
| Parameter | Role in email previewing |
|---|---|
html | Pass raw email HTML directly, no URL needed |
url | Capture a hosted email template or "view in browser" link |
width | 600px for standard email, 375px for mobile, 320px for small screens |
dark_mode | Preview email in dark mode (Chromium simulation) |
format | PNG for crisp previews, JPEG for lighter files, WebP for thumbnails |
quality | Adjust compression for JPEG/WebP output |
full_page | Capture the complete email, not just the viewport |
delay | Wait for web fonts or remote images to load before capture |
css | Inject prefers-color-scheme: dark or client-specific overrides |
omit_background | Transparent background for email screenshots on custom backdrops |
resize_width | Generate thumbnail-sized previews for template pickers |
webhook_url | Async processing for batch template preview generation |
cache_ttl | Disable caching (0) for fresh renders during development |
Preview Your First Email Template
Start Free - 200 ScreenshotsEmail preview testing doesn't need to cost $500 a month. An email preview screenshot API handles the development workflow for roughly 2% of Litmus's monthly cost: render your HTML, check it at desktop and mobile widths, verify dark mode, and move on. For teams building dynamic images from HTML templates, the same API covers both email previews and social card generation. To add visual regression to your email template CI/CD pipeline, the visual regression testing guide covers the comparison workflow. For rendering complete email reports as PDF attachments, see the website to PDF feature. And the Puppeteer vs screenshot API comparison explains why managing your own browser infrastructure for email rendering adds complexity you don't need.