How to convert an html email template to a pdf for review
- Step 1Export the template's HTML from your ESP or builder — Pull the raw
.htmlfrom your ESP (Mailchimp, Klaviyo, Braze, etc.) or design tool. Most builders offer an 'Export HTML' or 'View HTML source' option. Save it as a.htmlfile. - Step 2Open the converter and drop the file — Load it into the HTML to PDF converter. It parses locally — the template never leaves your browser. Upload is the only input; there's no paste box.
- Step 3Let it strip styles and flatten the tables — The converter removes
<style>/<script>, turns each tag (including<table>,<tr>,<td>) into a line break, and decodes the four core entities. Output is 10pt Helvetica on US-Letter — no width or page-size control. - Step 4Treat the output as a copy proof, not a design proof — Read the PDF for wording: headline, body, CTA text, unsubscribe/legal footer. The visual layout, fonts, and images are gone, so don't use this to approve the look — only the language.
- Step 5Circulate for sign-off — Share the PDF with stakeholders or legal for copy approval. Because it's text-selectable, reviewers can highlight and comment on exact phrases.
- Step 6Produce a visual proof separately — For the design sign-off, send the email to yourself (or a seed inbox), screenshot it, and run the screenshot through image-to-pdf — or use Litmus / Email on Acid for true multi-client rendering.
Email HTML feature → PDF outcome
How the converter's text-extraction handles the constructs common in email templates.
| Email construct | Outcome in PDF | Note |
|---|---|---|
| Body copy, headlines, CTA labels | Kept as text | All readable copy survives, in document order. |
Nested <table> layout | Flattened to lines | Cell text becomes separate lines; the grid is not reconstructed. |
| Inlined CSS (the email default) | Discarded | style= attributes and <style> blocks are removed. |
| Hero image / banner | Discarded | No image embedding; alt text inside other tags may or may not survive depending on placement. |
| Bulletproof / VML buttons | Label kept, styling lost | The button's text shows; the shape, color, and Outlook VML do not. |
| Preheader text | Kept as text | Often hidden in email via CSS — here it appears as plain text since CSS is gone. |
Merge tags (*|FNAME|*, {{name}}) | Shown literally | Unrendered personalization tokens appear as-is — review them before approval. |
| Unsubscribe / legal footer | Kept as text | Useful for the compliance read-through. |
Copy proof vs design proof
Match the tool to what the reviewer is actually approving.
| Reviewing… | Use | Why |
|---|---|---|
| Wording, tone, legal copy | html-to-pdf (this tool) | Strips markup so reviewers read clean copy. |
| Visual design / layout | Screenshot → image-to-pdf | Preserves the rendered look; this tool can't. |
| Cross-client rendering (Outlook etc.) | Litmus / Email on Acid | Renders in real clients; no converter substitutes for this. |
| Authored content with headings | markdown-to-pdf | Styles headings/bold if you control the source. |
Cookbook
Copy-review recipes for email templates. 'Before' is the template HTML; 'after' is the text in the PDF proof.
Pulling clean copy from an inlined template
Real email HTML is wall-to-wall inline CSS and nested tables. The converter throws all of that away and leaves the words — exactly what a copy reviewer wants.
Before (email HTML, abridged): <table><tr><td style="font:24px Georgia;color:#222"> Summer Sale — 30% Off</td></tr> <tr><td style="font:14px Arial">Ends Sunday. Shop now.</td></tr></table> After (PDF text): Summer Sale — 30% Off Ends Sunday. Shop now.
Unrendered merge tags show up — catch them before send
Because nothing is personalized, raw merge tags appear literally. That's actually a useful QA pass: spot any token you forgot to wire up.
Before:
<p>Hi *|FNAME|*, your order {{order_id}} shipped.</p>
After (PDF text):
Hi *|FNAME|*, your order {{order_id}} shipped.
(reviewer flags: confirm FNAME + order_id are mapped)Preheader text becomes visible
Preheaders are usually hidden with CSS in the inbox. With CSS stripped, the preheader appears as ordinary text — handy to confirm it reads well, since it shows in inbox previews.
Before: <div style="display:none;max-height:0">Your weekly digest is here</div> <h1>This Week in Product</h1> After (PDF text): Your weekly digest is here This Week in Product
Tables flatten — don't approve layout from this
A two-column feature block collapses to four stacked lines. Fine for reading copy; useless for judging the visual arrangement.
Before (2-col layout): <td>Feature A</td><td>Feature B</td> <td>Fast and simple</td><td>Reliable and secure</td> After (PDF text): Feature A Feature B Fast and simple Reliable and secure
The visual proof goes through image-to-pdf
Send a seed email, screenshot the rendered message at desktop and mobile widths, then combine the screenshots into a PDF with image-to-pdf for the look-and-feel approval.
1. Send template to seed inbox 2. Screenshot rendered email (desktop + mobile) 3. image-to-pdf → proof.pdf (each shot = one page) 4. Send proof.pdf for DESIGN approval; send this tool's PDF for COPY approval
Edge cases and what actually happens
The client expects to see the design
By designThis is a copy proof, not a design proof — CSS, images, fonts, and the responsive layout are all stripped. For appearance sign-off, screenshot the rendered email and use image-to-pdf, or use Litmus / Email on Acid.
Outlook-specific VML / conditional comments
Not renderedThe converter uses no email engine. VML buttons, <!--[if mso]> conditionals, and ghost tables don't render — only their fallback text (if any) survives. Validate Outlook rendering in a real client or Litmus.
Merge tags appear unrendered
Expected*|FNAME|*, {{name}}, and similar tokens show literally because nothing is personalized here. Treat it as a QA opportunity to confirm every token is mapped before send.
Hidden preheader text becomes visible
ExpectedCSS-hidden preheaders (display:none) show as plain text once CSS is stripped. Not a bug — and a good chance to proof the preheader copy that appears in inbox previews.
Multi-column blocks collapse to one column
FlattenedTable-based columns flatten to stacked lines. Reading order is preserved but the visual arrangement is gone. Don't approve layout from this output.
Emoji or accented characters in subject/body
Render errorHelvetica is Latin-1, so emoji and non-Latin characters can't be drawn and may error or drop. Proof those via a screenshot through image-to-pdf.
Long pre-wrapped link or tracking URL
TruncatedLines clip at 100 characters with no wrap, so long tracked URLs lose their tails. The link text matters for review, not the URL — but be aware the full link won't show.
Template exported as a .zip or multi-file bundle
Unsupported formatThe tool reads a single .html/.htm file. Extract the main HTML from the bundle and upload that one file.
Frequently asked questions
Will the email render the way it looks in an inbox?
No. This extracts the copy into plain text; CSS, images, fonts, and the responsive layout are stripped. Use it for a wording/legal review. For a visual proof, screenshot the rendered email and use image-to-pdf, or use Litmus / Email on Acid.
Will Outlook-specific HTML render correctly?
No — there's no email rendering engine at all. VML buttons and <!--[if mso]> conditionals are ignored; only fallback text survives. Always validate Outlook in a real client or a testing service before sending.
Can I see responsive mobile views?
No. There's no viewport or width control, and media queries (CSS) are stripped. To proof mobile, screenshot the email at a phone width and combine the shots with image-to-pdf.
Can I set the page width to email width (e.g. 600px)?
No. Output is always US-Letter (612×792pt) and there's no width setting. The tool lays text in a single column regardless of the email's design width.
Why do I see *|FNAME|* and {{name}} in the PDF?
Nothing is personalized, so merge tags appear literally. Use it as a QA check — confirm every token is mapped in your ESP before you schedule the send.
My preheader text shows up — is that wrong?
No. Preheaders are usually hidden with CSS; once CSS is stripped they appear as text. It's a useful chance to proof the preheader copy that shows in inbox previews.
Will the hero image and buttons appear?
No images — the converter draws text only. Buttons keep their label text but lose all styling. For the visual elements, use a screenshot through image-to-pdf.
Can I share the PDF as a template proof to clients?
Yes, for copy approval — it's a clean, commentable text proof. For design approval, pair it with a visual proof (screenshot → image-to-pdf or a Litmus capture). Always test the live HTML in real clients before sending the campaign.
Is my client's template uploaded anywhere?
No. Conversion is fully in-browser via pdf-lib, so unreleased campaigns and client work stay on your device. Only anonymous usage counts are recorded when signed in.
Will emoji in the subject or body come through?
No. The PDF uses Helvetica (Latin-1), which can't render emoji or non-Latin text. Proof those via a screenshot through image-to-pdf.
Do tables in my email keep their structure?
No. Email table layouts flatten to one line per cell in reading order. Good for reading copy, not for judging the column arrangement.
What size template can I convert for free?
Up to 2 MB on the free tier (one file). Pro raises it to 50 MB and allows 5-file batches — useful for proofing a series of campaign emails at once.
Privacy first
All PDF processing runs locally in your browser using PDF-lib and pdf.js. No file is ever uploaded — only metadata counters are saved for signed-in dashboard stats.