HTML checks vs. rendered-email compliance checks: what's the difference?

Two very different questions

Every automated email compliance check answers one of two questions. The first is “what does the code say?” The second is “what does the recipient see?” They sound like the same question. They are not, and the gap between them is exactly where compliance teams get caught out.

An HTML checkparses the raw source of an email — the markup, the CSS, the link attributes, the alt text — and reasons about compliance from that text. A rendered-email checkfirst builds the email the way a mail client would, produces the actual pixels a subscriber would open, and then inspects that image. For regulated marketing — iGaming bonus offers, financial promotions, anything with a mandatory disclaimer — the difference decides whether your tooling is measuring the right thing at all.

This article breaks down what each approach is genuinely good at, where source-only inspection goes blind, and why the rendered result is the version an auditor will actually judge you on. RuleRun is built around the second question, but the honest answer is that both approaches have a place.

What HTML source checks are good at

Source inspection is fast, cheap, and deterministic. You can run it on every commit, on every template, in milliseconds, with no browser and no rendering farm. When the thing you care about is literally present as text or as an attribute in the markup, an HTML check is often the right tool.

• Missing alt text. Every <img> without an altattribute is trivially detectable in the source — and invisible in a screenshot.
• Raw link URLs. HTML parsing reads the actual href destination, including tracking redirects and unapproved domains, before any client rewrites it.
• Live text strings. If a required disclaimer sits in real HTML text, a string or pattern match confirms its presence instantly.
• Structural rules.Presence of an unsubscribe link, a physical postal address block, or a specific UTM parameter — all readable straight from markup.
• Encoding and deliverability hygiene. Broken tags, unclosed elements, and oversized payloads surface at the source level long before they reach an inbox.

What HTML checks miss

The trouble starts the moment compliance depends on appearance rather than presence. A source parser sees a tag; it does not see a rendered pixel. Here is where that blindness bites hardest.

• Text baked into images.Marketing emails routinely ship the whole hero — headline, bonus offer, even the terms — as a single image. Your mandatory disclaimer might be perfectly visible to a human and completely absent from the HTML text a parser can read.
• Visual prominence and hierarchy.“Terms apply” may be present in the markup but rendered at four pixels, greyed out, and pushed below the fold. The source says compliant; the render says buried.
• Colour contrast. Light-grey disclaimer text on a white background is technically present and practically unreadable. Contrast is a rendered property, not a source one.
• Dynamic and personalised content. Merge fields, AMP blocks, and conditional sections mean the template source is not the message anyone actually receives.
• Dark-mode rendering.Clients invert and recolour emails aggressively. A disclaimer that reads fine in light mode can vanish against a re-tinted background — something no source check can predict.
• Client-specific rendering.Outlook’s engine, Gmail’s clipping, and Apple Mail’s CSS support all diverge. The same HTML produces materially different inboxes.
• Hidden and clipped text. display:none, zero-height containers, off-canvas positioning, and Gmail’s message-clipping all remove content from view while leaving it in the source.
• CSS that shrinks or masks content. A required phrase set to font-size:0, opacity:0, or the same colour as its background passes a string match and fails a human.

Why the render is the compliance ground truth

When a regulator, an auditor, or an affiliate compliance team reviews a promotion, they do not open the HTML. They open the email. They judge the disclaimer that appeared, at the size it appeared, in the place it appeared, in the colour it appeared. The rendered result — the pixels a recipient saw — is the artefact under examination.

This is not a technicality. Most advertising and financial-promotion standards are written in terms of what is clear, prominent, and legible to the consumer. Those are properties of the rendered output. A disclaimer that exists only as unreadable markup satisfies the letter of a string match and none of the intent of the rule. If your evidence trail is built from source, you are documenting a message your subscribers never received.

That is why RuleRun treats the rendered email as the primary subject of every check, and keeps the screenshot and PDF of that exact render as the evidence attached to each result.

Side by side

Two pipelines, two very different views of the same email.

When HTML checks are enough — and when they are not

HTML checks alone can be sufficient when…

• The rule is purely structural: an unsubscribe link exists, a postal address block is present, a UTM tag is set.
• You are validating link destinations against an approved-domain list before send.
• You control the template and can guarantee required text ships as live, styled HTML — not imagery.
• You need a fast gate in CI, and a full render on every commit would be too slow.

Rendered checks become essential when…

• Any required content — logos, disclaimers, terms — can appear inside images.
• The rule is about prominence, size, contrast, or position rather than mere presence.
• Content is personalised, conditional, or assembled dynamically at send time.
• You must produce audit-ready evidence of what recipients actually saw.
• Dark mode or a specific client’s rendering could change legibility.

How RuleRun checks the real thing

RuleRun starts where source-only tools stop. Instead of reasoning about markup, it renders the email the way a mail client would, captures the actual result, and then runs a layered inspection over those pixels.

• Faithful rendering. The email is built into the image a subscriber would open, so every check operates on the real thing rather than an approximation of it.
• Computer vision for assets.Required logos and brand marks are detected visually — whether they arrive as inline images, background graphics, or part of a composite hero.
• OCR for text in images. Disclaimers, bonus terms, and mandatory phrases baked into artwork are read out of the pixels, so they count exactly as live text would.
• Prominence and layout measurement.Text height, position, and relationship to the headline are measured against your thresholds — catching the buried four-pixel “terms apply” a string match waves through.
• Link verification.Destinations are still checked against approved lists — combining the source-level strength of HTML inspection with the visual truth of the render.
• Evidence on every run. Each result carries the screenshot and a PDF of the exact render, so your compliance record shows what recipients saw, not what a template hoped they would.

The result is a check that answers the question that actually matters — “what did the recipient see, and does it comply?”— and backs the answer with evidence an auditor can accept.