You've been through the approval cycle. The designer exports a beautiful PDF of the email campaign. Marketing signs it off. Legal gives the nod. The email goes to build. Then it goes live.
And then someone on your team opens it in Outlook and it looks nothing like what everyone approved.
This scenario plays out constantly in marketing teams, and the root cause isn't carelessness or bad design. It's a fundamental mismatch between what PDF approval can verify and what HTML email rendering actually does. If your campaign review process still relies on PDF sign-off as the final gate, you're approving a fiction.
Our article explains why that gap exists, what it costs, and how to structure an HTML email review process that actually catches problems before they reach the inbox.
A PDF of an email design is a static snapshot. It shows you one version of how the email could look, in a perfect rendering environment, at a fixed viewport width, with images loaded and fonts applied exactly as intended.
What it doesn't tell you is how the email will look in Gmail on an Android phone. Or in Outlook 2019 on Windows 11. Or in Apple Mail with dark mode switched on. Or for the share of your audience who have images blocked by default.
The gap between the PDF and the live HTML isn't cosmetic. It can mean:
None of these failures are visible in a PDF. All of them are visible to your subscribers.
The web standardization that happened over the past decade largely passed email by. Browsers like Chrome, Firefox, and Safari converged on shared rendering standards years ago. Email clients never did.
Each client uses its own rendering engine with its own interpretation of HTML and CSS. Gmail strips embedded style blocks and enforces its own CSS rules. Outlook for Windows uses Word's engine, which ignores modern CSS features like flexbox and treats certain layouts completely differently from any browser. Apple Mail uses WebKit and behaves more like a browser, but introduces its own dark mode behavior. Yahoo, Samsung Mail, and a dozen other clients each add their own layer of variation.
Multiply that by operating system, device type, screen resolution, browser (for webmail), and whether dark mode is active, and the number of distinct rendering environments for any given campaign can exceed fifty.
A PDF approval process doesn't just miss some of these environments. It misses all of them.
The consequences of catching rendering problems after send range from annoying to genuinely costly.
Brand consistency. An email that renders with the wrong font, missing images, or a broken layout reflects poorly on the brand regardless of what the approved PDF showed. Stakeholders who signed off on a polished design often don't connect the broken live email with a flawed review process. They just know it looks wrong.
Campaign performance. Broken calls-to-action, collapsed layouts, and invisible buttons don't just look bad. They directly reduce click-through rates. If the primary conversion element of a campaign doesn't render correctly in Outlook, and Outlook accounts for a significant share of your audience's inboxes, you've undermined your own campaign.
Compliance exposure. For regulated industries, marketing creative must not only look correct but also contain the right content in the right order. An email that renders differently from what was approved creates a gap between what was signed off and what was delivered. That's a harder position to defend in an audit. For more on how approval process failures compound in regulated environments, our article on the hidden costs of email-based creative approvals covers this in more detail.
Wasted revision cycles. Catching a rendering issue post-send is worse than catching it pre-send, but catching it after approval and before send is still inefficient. Post-production rework requires re-opening the approval cycle, which costs time and creates version confusion.
Replacing PDF approval with a more robust process doesn't mean adding complexity for its own sake. It means reviewing the asset in the format and environment in which it will actually exist.
Here's what effective HTML email review looks like in practice.
1. Review the live HTML file, not a static export
Stakeholders should be reviewing the actual coded email in a browser-rendered environment, not a flattened image. This means giving reviewers access to the HTML build for annotation and sign-off, with the same kind of structured workflow that print and packaging teams have used in online proofing for years. The format being reviewed should be the format being sent.
2. Test across client environments before approval gates
Client rendering tests should be completed before, not after, stakeholder review. There's no point gathering sign-off on content that hasn't yet been validated for the environments where it will be read. Once the rendered HTML is confirmed stable across priority clients, that validated version enters the approval cycle.
3. Define your priority client matrix based on audience data
Not all email clients are equally important for every campaign. Pull open data by client type for the relevant audience segment and build a testing priority list. A B2B campaign to enterprise accounts probably needs to be bullet-proof in Outlook. A DTC brand communicating with a younger audience might weight iOS Mail and Gmail more heavily. The testing matrix should reflect actual audience behavior, not a blanket assumption.
4. Include dark mode in the review
Dark mode adoption is significant and growing. Estimates place 35-50% of email opens in dark mode across various audiences, with some Apple Mail user segments considerably higher. An HTML email that hasn't been reviewed in dark mode hasn't been properly reviewed. The approved version should be validated in both light and dark mode before sign-off.
5. Review on mobile, not just desktop
PDFs are almost always reviewed at desktop scale. But a significant share of email opens happen on mobile devices. If your approval process doesn't include a mobile rendering check, you're not seeing the experience that a large portion of your subscribers will have.
6. Gate the approval on the HTML, not the design mockup
This is the critical change. Approval workflows should be triggered by the coded HTML build, not the design file. The PDF or Figma mockup remains useful for design direction and early creative alignment. But the formal approval gate, the one that authorizes the campaign to send, should reference the actual asset in the format it will reach subscribers.
For teams managing high volumes of email campaigns alongside other content types, the HTML email review problem is often part of a larger process challenge. Different assets - PDFs, images, HTML, video, packaging, and digital ad creative - are reviewed in different tools with different approval records. Feedback is scattered. Version control is manual. There's no single view of what's been approved and what hasn't.
Structured online proofing platforms address this directly. DALIM FUSION supports review and approval of HTML files alongside other content types in a unified environment. Stakeholders can annotate directly on the rendered asset, work through a configurable approval workflow, and leave a documented audit trail regardless of the format under review. For teams that manage multi-channel campaigns where an email, a web banner, a social asset, and a print insert all need to be reviewed and approved before a launch date, having those review cycles in one place makes a material difference to how efficiently the process runs.
If you're currently evaluating platforms and want to understand what to look for, our guide to choosing online proofing software walks through the right questions to ask before you decide.
The underlying principle is the same whether you're using a specialist platform or building a process manually: approval should happen on the real asset, in a format that represents how it will actually be experienced. For HTML email, that means reviewing HTML.
Even teams that move away from PDF-only approval can fall into patterns that undermine the improvement.
Reviewing screenshots instead of live HTML. Screenshots of email renders are better than PDFs but still static. They don't account for interactive elements, dynamic content, or the actual behavior of the asset in a real inbox environment.
Testing on too few clients. Teams often test in Gmail and Outlook and call it done. Priority clients vary by audience, and a basic two-client test can still miss significant rendering failures for a meaningful share of recipients.
Approving the design file instead of the build. Stakeholder sign-off on a Figma or PSD design doesn't authorize the HTML. The design and the build are two different things, and changes happen in translation.
Running rendering tests after approval. The sequence matters. Rendering validation should gate entry to the approval cycle, not follow it.
Neglecting accessibility. The Email Markup Consortium's 2026 Accessibility Report, which analyzed over 376,000 HTML emails, found that the vast majority still contain accessibility issues categorized as "Serious" or "Critical." The most common failures - missing language attributes, poor color contrast, absent alt text, and broken heading hierarchy - have remained largely unchanged year on year. An approval process that doesn't include accessibility checks is missing a growing area of risk, particularly for brands operating in regulated markets or those subject to W3C's Web Content Accessibility Guidelines (WCAG 2.2), which became an ISO standard in 2025 and underpins the European Accessibility Act and comparable US requirements.
Why does HTML email look different in different email clients?
Email clients use their own rendering engines to interpret HTML and CSS, and those engines don't follow a unified standard the way modern web browsers do. Outlook for Windows uses Microsoft Word's engine, which has limited CSS support. Gmail strips certain style blocks. Apple Mail uses WebKit. The result is that identical HTML code can produce significantly different layouts, fonts, spacing, and behavior depending on which client opens it.
Can you approve HTML email campaigns from a PDF?
PDF approval is only appropriate for verifying design intent, not for authorizing a campaign to send. A PDF doesn't capture how the HTML will render across different email clients, devices, or display modes. Using PDF sign-off as the final approval gate means stakeholders are approving a static design file rather than the actual asset subscribers will receive.
What should be included in an HTML email approval process?
An effective HTML email approval process should include client rendering tests across priority environments before stakeholder review begins; mobile and dark mode checks; annotation and feedback on the live HTML build rather than a static export; a structured approval workflow with defined reviewers and sign-off stages; accessibility validation against WCAG 2.2; and a version-controlled record of what was approved and when.
How do you test HTML emails across different email clients?
Email testing tools generate previews of how an HTML email will render across a large number of client, device, and operating system combinations. The priority client list should be weighted by audience data rather than attempting to achieve perfect rendering everywhere. Core clients in the audience's device mix should be validated before the email enters the approval cycle.
What is dark mode email rendering and why does it matter?
Dark mode is an operating system or app setting that switches the UI to dark backgrounds with lighter text. Email clients implement dark mode differently: some automatically invert colors, some partially adjust elements, and some leave emails untouched. An email designed for light backgrounds can become unreadable in dark mode if it hasn't been specifically tested, with light text potentially invisible against a dark background.
What does the Email Markup Consortium's accessibility research show?
The Email Markup Consortium's annual reports consistently find that the vast majority of HTML emails contain accessibility issues rated "Serious" or "Critical." Their 2026 report, based on over 376,000 emails, shows only marginal improvement year on year. The most common failures include missing language direction attributes, insufficient color contrast, absent alt text, and broken heading structure - systemic issues baked into standard templates and processes, not edge cases.
How does WCAG apply to HTML email campaigns?
WCAG (Web Content Accessibility Guidelines), published by the W3C, is the internationally recognized standard for digital content accessibility. WCAG 2.2 was approved as an ISO standard in 2025 and underpins the European Accessibility Act as well as comparable requirements under US law. Its core principles - perceivable, operable, understandable, and robust - apply directly to HTML email. Teams in regulated industries or operating across the EU and US should treat WCAG 2.2 Level AA as a baseline for campaign review.
How does HTML email review fit into multi-channel campaign approval?
For teams running campaigns across email, print, digital, and social, managing HTML email review separately from other asset types creates version confusion and fragmented audit records. Platforms like DALIM FUSION that support review and approval of multiple file types within a unified workflow environment give teams a single record of what's been approved across all campaign assets, and reduce the risk of the wrong version of any asset going live.
1 min read
Rebecca Freeman : May 13, 2026 8:45:00 AM
You know the drill. A designer exports a file, attaches it to an email, and sends it off for approval. The reviewer opens it, adds comments in the...
/3.png)
1 min read
Rebecca Freeman : Jun 10, 2026 2:13:18 PM
If you work in print or packaging production, the gap between receiving a file and sending it to press has always been where things go wrong. Fonts...
1 min read
Rebecca Freeman : Apr 28, 2026 3:38:46 PM
Rebecca Freeman