Email to Image API — Convert Email HTML to PNG, WebP, and PDF

You have the HTML code of an email newsletter, and you need an image of it. Maybe for a dashboard, maybe for an archive, maybe for a social media post. Opening it in a browser and taking a manual screenshot works once, but it doesn't scale. Doing it programmatically means setting up a headless browser, picking the right viewport width, and handling all the quirks of email markup.

ScreenshotRun's email to image API takes a simpler approach. You send the email HTML through the html parameter, set the width to 600 pixels, and get back a PNG, WebP, or PDF. One request instead of a whole infrastructure. No test sends, no browser to manage.

How the email to image API works

The html parameter accepts any HTML you pass to it, including email templates with tables and inline styles. Set width=600 because that's the standard width most email clients use, and the API renders it exactly like Chrome would. For the general HTML rendering reference, see HTML to Image.

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\" align=\"center\" style=\"background:#ffffff;\"><tr><td style=\"padding:40px 30px; font-family:Arial,sans-serif;\"><h1 style=\"margin:0 0 20px; color:#333;\">Your order has shipped</h1><p style=\"margin:0; color:#666; line-height:1.6;\">Tracking number: 1Z999AA10123456784</p></td></tr></table></body></html>",
    "width": 600,
    "format": "png"
  }'

This is a real email structure: a centered 600px table with inline styles on every element. One request, and you get a PNG that looks like what a subscriber sees in Gmail or Apple Mail. The API loads external images, applies all the inline CSS, and captures the full height of the email.

Why email HTML is different from regular HTML

If you've only worked with web HTML, email markup might look strange. It's built with different rules because email clients are years behind browsers.

The biggest difference is tables. Email templates use <table> elements for layout because Outlook's desktop client doesn't support flexbox or grid. It renders HTML using Microsoft Word's engine, so everything has to be nested tables with cellpadding and cellspacing. The good news: Chromium handles tables perfectly. They just work.

Same with inline styles. Gmail strips out any <style> blocks from the email's <head>, so email developers put every style directly on each element. Chromium reads inline styles like regular CSS, so nothing breaks during rendering.

You'll also see Outlook conditional comments like <!--[if mso]> in the markup. These are fallbacks for Word's rendering engine. Chromium ignores them completely and renders the standard HTML. That's exactly what you want for generating images.

One thing to watch out for: external images. If your email links to images on a CDN, the API loads them automatically. But if those URLs need authentication or sit behind a firewall, they won't show up. All image URLs need to be publicly accessible.

Render the same email at different screen sizes

Most emails are designed for 600px wide screens. But people also read them on phones (375px) and tablets (480px). If your email template is responsive, it rearranges content at smaller widths using media queries.

You can render the same email HTML at all three widths in one go:

// Node.js — render an email at desktop, tablet, and mobile widths
const widths = [600, 480, 375];
const emailHtml = fs.readFileSync('welcome-email.html', 'utf-8');

for (const width of widths) {
  const response = await fetch(
    'https://api.screenshotrun.com/v1/screenshots/capture',
    {
      method: 'POST',
      headers: {
        'Authorization': 'Bearer YOUR_API_KEY',
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        html: emailHtml,
        width,
        format: 'webp',
        quality: 85
      })
    }
  );
  const buffer = await response.arrayBuffer();
  fs.writeFileSync(`email-${width}px.webp`, Buffer.from(buffer));
}

You get three images back. The 600px version shows columns side by side. At 480px they might stack. At 375px you see the single-column mobile layout. This is useful for dashboards that need to show how the same email looks on different devices. For a complete email testing workflow, see Email Previews.

Where people actually use this

The most common case I've seen is campaign dashboards. Platforms like Klaviyo or Mailchimp show your email campaigns as rows of text: subject line, date, open rate. That's hard to browse. Add a thumbnail of the actual email next to each row, and suddenly a marketing manager can scan through 50 campaigns visually instead of clicking into each one.

Then there's compliance. Companies in finance (FINRA, SEC), healthcare (HIPAA), and public markets (SOX) have to keep emails for years. Printing to PDF from a mail client rarely keeps the original layout. Forwarding strips and modifies the HTML. An email screenshot API call captures exactly what the recipient saw, pixel for pixel. Use format=pdf for document archives, or format=png for image storage.

Know those CRM entries that just say "Email sent: Follow-up #3"? In HubSpot or Salesforce, that text tells a sales rep nothing about what was actually sent. Swap it for a visual preview, and the context is immediate.

Newsletter creators use it for social media too. Instead of linking to a web version that most followers won't click, they post an image of the email itself. One API call to convert email HTML to PNG, and it's ready to share.

Dark mode email rendering

Some email clients (Apple Mail, Outlook for Mac, Gmail app) switch to dark mode based on the user's system settings. If your email template has @media (prefers-color-scheme: dark) rules, you can test them without changing your system theme.

Just add dark_mode=true to the request. The API tells Chromium to activate dark color scheme preferences, and your email renders in its dark mode version.

curl -X POST "https://api.screenshotrun.com/v1/screenshots/capture" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "html": "<!-- your email HTML with @media (prefers-color-scheme: dark) -->",
    "width": 600,
    "dark_mode": true,
    "format": "png"
  }'

Render the same template twice (with and without dark_mode) and you have a side-by-side comparison for your design review. More on dark mode rendering on the dark mode feature page. If you're building a full email testing pipeline, the Email Previews use case walks through the workflow.

PDF output for email archiving

If you need to archive emails rather than preview them, PDF is usually the better choice. PDFs are self-contained, you can search text inside them, and they're accepted as records in legal and compliance processes.

curl -X POST "https://api.screenshotrun.com/v1/screenshots/capture" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "html": "<!-- email HTML -->",
    "width": 600,
    "format": "pdf",
    "pdf_page_format": "A4",
    "pdf_margin_top": "10mm",
    "pdf_margin_bottom": "10mm"
  }'

The email renders on an A4 page with margins. If the email is longer than one page, it splits automatically. You can add response_type=base64 to get the PDF as a string instead of a file download, or set up a webhook if you're archiving thousands of emails at once. More on PDF rendering in the Website to PDF guide.

What this can and can't do

I want to be upfront here. The API renders email HTML in Chromium, the same engine that powers Gmail's web client and the new Outlook for Windows. So the output matches what those clients show. But it doesn't simulate how emails look in Outlook desktop (which uses Word's engine), Yahoo Mail, or how Gmail strips out <style> blocks.

If you need to see your email in 50+ real clients, that's what Litmus and Email on Acid do. They start at $99/month and go up from there.

But most people converting email HTML to images don't need cross-client simulation. They need a clean image for a dashboard, an archive, or a social post. For that, Chromium rendering does the job at a fraction of the cost.

Email to image API parameter reference

All other API parameters work here too: base64 response for inline embedding, format and quality settings, transparent backgrounds for isolated elements, and HTML to image for non-email HTML. Full parameter list in the API docs.

One thing worth knowing: if your email template loads web fonts via @import, Chromium renders them perfectly, but most real email clients don't support web fonts at all. So the screenshot might look better than what subscribers actually see. Keep that in mind if you're using these images for accuracy checks.