How to Capture an HTML Email Preview in a Browser as a Client Proof

To capture an HTML email as a client proof, render the exact email draft in a browser, choose the desktop or mobile-width viewport the client should review, then save a viewport or full-page screenshot. Use a PDF if a paginated document is more useful. Label the artifact with the email version and the view it represents. A browser screenshot shows that browser’s rendering at capture time; it does not prove how the message renders in Gmail, Outlook, Apple Mail, or other email clients.

This guide covers manual Chrome and Firefox capture, repeatable Chrome Headless commands, review handoff, troubleshooting, and when to use email-client previews instead.

1. Prepare the email draft for review

1. Open the exact HTML version intended for client review. Keep the source or draft identifier so the proof can be tied to that version.
2. Render the HTML in a browser. If it is a local file, open it directly; if it is hosted, use the review URL that represents the actual draft.
3. Check that remote images, fonts, and other assets have loaded. Confirm that the page has stopped changing before capturing.
4. Decide what the client is being asked to review: desktop layout, a mobile-width layout, the first screen, or all content in the email.

Do not silently change the HTML or its assets during capture. If you make a correction, capture the revised version and identify it as a new version.

2. Choose a viewport and capture extent

A viewport screenshot captures what is currently visible. It is usually easier to inspect at readable scale and works well when the first screen is the review target. A full-page screenshot includes content below the fold, which is useful for a long email but may shrink the content when viewed as one image.

For a mobile proof, use browser device emulation or set a narrow viewport. Capture desktop and mobile-width versions separately when both matter; one image cannot show both layouts clearly. Chrome DevTools documents device emulation and its screenshot commands, including full-size capture of content outside the current viewport. Chrome DevTools documentation · Chrome Device Mode documentation

3. Capture manually in Chrome or Firefox

Chrome DevTools

1. Open the rendered email page in Chrome.
2. Open DevTools. Enable the device toolbar if you need to inspect a mobile-width layout, then choose a device preset or set the viewport dimensions.
3. Open the DevTools command menu and search for a screenshot command. Choose a capture of the visible area for a viewport proof, or the full-size screenshot command for the entire page.
4. Save the resulting image and inspect it for clipping, missing assets, unexpected scaling, and content that changed during capture.

Firefox DevTools

Firefox provides full-page screenshots and screenshots of a selected element in the Inspector. Its Web Console screenshot helper also supports a --fullpage option. Use an element capture when the email sits inside a larger page and the review should show only the email itself. See Firefox’s screenshot documentation for the available controls.

4. Make a repeatable capture with Chrome Headless

For repeated captures, Chrome Headless can write a screenshot or print the page to PDF. Replace the URL with the page containing the exact rendered draft. These examples assume a Chrome executable available as google-chrome; use the executable name or full path for your installation.

Screenshot at a chosen viewport

google-chrome --headless --no-sandbox --disable-gpu \
  --window-size=600,900 \
  --screenshot=email-proof.png \
  --timeout=5000 \
  "file:///absolute/path/to/email-preview.html"

--window-size sets the viewport dimensions in pixels. Use dimensions representative of the review target. --timeout sets a maximum wait interval before capture; it does not guarantee that every remote asset has loaded, so inspect the output. Consult the Chrome Headless command-line reference for current command options. Full-page behavior and viewport sizing can vary with Chrome versions; verify the output when a full email is required.

Print to PDF

google-chrome --headless --no-sandbox --disable-gpu \
  --print-to-pdf=email-proof.pdf \
  --no-pdf-header-footer \
  --timeout=5000 \
  "file:///absolute/path/to/email-preview.html"

PDF is useful when the client needs a printable or paginated artifact. Check page breaks, margins, and scaling before sending. Browser print output can differ from a screenshot, and neither format is an email-client rendering test. Chrome documents --print-to-pdf, --no-pdf-header-footer, and --timeout in the Headless reference linked above.

On systems where Chrome refuses to launch as root, --no-sandbox may be needed in a controlled local capture environment. Avoid treating that flag as a general production security setting; follow the security requirements of the environment where the browser runs.

5. Package the proof for client feedback

• Use a descriptive filename, such as spring-campaign-v4-desktop-full-page.png.
• Identify the email name or draft version and the capture view: desktop or mobile-width, viewport or full-page, and image or PDF.
• Include a capture date if it helps distinguish review rounds.
• Ask for specific feedback or approval and keep the approved version associated with the proof.
• Before sharing a link, check whether anyone with the link can view it and whether the draft contains confidential content.

A screenshot is a review artifact; by itself it does not record formal approval. If you need comments or approval tracking, use a proofing workflow that supports those controls. Litmus describes its Proof feature as an HTML view rendered in the desktop browser, with sharing and collaboration options; it also notes that a public share link can be viewed by anyone who has it. Confirm current plan entitlements and sharing settings directly with the provider. Litmus Proof documentation · Litmus approvals documentation

6. Know what the proof does and does not establish

The artifact establishes what the selected browser rendered at the capture time and viewport, assuming it corresponds to the stated HTML version. It can help a client comment on layout, copy, imagery, hierarchy, and broad visual presentation.

It does not establish how the email renders in specific mail clients. Litmus explicitly distinguishes its browser-rendered Proof view from client rendering. If the client asks about recipient experience across email clients, run client-specific previews and relevant pre-send checks, then state which clients and versions were checked. Do not label a browser screenshot as an all-client test. See the separate Litmus Previews & QA guide.

Or skip the browser setup

ScreenshotNeo can capture a rendered email preview page with one API request. Create or use a page URL that displays the email draft, then substitute that URL in the request below. The ScreenshotNeo API documentation describes the available parameters.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com/email-preview \
  -o email-proof.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={
        "access_key": "YOUR_API_KEY",
        "url": "https://example.com/email-preview",
    },
    timeout=90,
)
r.raise_for_status()
with open("email-proof.webp", "wb") as f:
    f.write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/email-preview',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const data = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('email-proof.webp', data));

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. Sign up for 1,000 free screenshots a month, with no card required.

7. Troubleshooting

Symptom	Likely cause	Fix
Images or fonts are missing	Remote assets have not loaded, are blocked, or require authentication.	Check the page in the same browser session, verify asset URLs and access, wait for loading to finish, and capture again. If the asset is private, use an authorized review environment.
The screenshot cuts off the email	A viewport capture was used, or the document had not finished laying out.	Use the full-page command or capture the email element in Firefox Inspector. Confirm the document height and inspect the output.
Text is too small in the full-page image	A long email was compressed into one tall image for display.	Capture readable sections or use a PDF with checked page breaks. A viewport image may be clearer for feedback on the first screen.
Mobile proof looks like desktop	The browser viewport was not changed, or the email markup does not respond at that width.	Enable device emulation or set an explicit mobile-width viewport, then capture a separate artifact. Check the HTML’s responsive styles.
Headless capture is blank or incomplete	The page was captured before rendering completed, navigation failed, or scripts/assets need more time.	Increase --timeout, check the URL and browser output, and verify the same page manually. A timeout is only a maximum wait, not proof that the page is ready.
PDF has unexpected headers or page breaks	Print settings include browser headers/footers or paginate the layout differently from the screen.	Use --no-pdf-header-footer, review print scaling and margins, and inspect every page before sharing.
Client assumes the screenshot proves Gmail or Outlook compatibility	The artifact’s scope was not stated clearly.	Label it as a browser-rendered proof and run client-specific previews if compatibility is part of approval.

8. Performance, reliability, and cost considerations

Manual DevTools capture is practical for a one-off proof and avoids maintaining a capture script. Headless capture is repeatable and can fit into a review process, but it depends on the browser installation, page availability, remote asset loading, and a sensible wait strategy. Keep the HTML version and capture parameters with the output so the artifact can be reproduced.

A screenshot or PDF avoids the need for a reviewer to open the source HTML, but very long captures can be awkward to inspect. Create separate desktop and mobile proofs when those are distinct review targets. Check file size and legibility before sharing.

Chrome and Firefox include the documented capture workflows above. A hosted screenshot API can reduce local browser setup for URL-based captures, but account for its plan limits and the fact that a capture of a web page still represents a browser page, not a matrix of email-client renderings. ScreenshotNeo’s listed plans are Free: 1,000 shots/month; Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; Business: $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan. Use client-specific email previews when the question is how recipients’ mail apps render the message.

FAQ

Should I send a screenshot or a PDF?

Send an image for quick visual comments on a particular viewport. Choose PDF when a printable or paginated artifact is useful, and inspect its page breaks first.

Can one screenshot cover desktop and mobile?

No. Capture separate representative viewport widths if both layouts need review.

Can a browser proof confirm email-client compatibility?

No. It shows a browser rendering. Use email-client previews and report the clients checked when compatibility is in scope.

Is a public proof link private?

Do not assume so. Check the service’s sharing behavior and limit access when the draft is sensitive.