Ask a compliance reviewer where the required disclaimer lives in a marketing email and the honest answer, more and more often, is: “somewhere inside a picture.” The responsible-gambling line, the age gate, the capital-at-risk warning — the exact text a regulator expects to see — is frequently rendered as pixels inside a hero banner rather than as selectable HTML text. That single shift quietly breaks most compliance tooling, because the tools were built to read source code, and source code no longer contains the words that matter.
This guide explains why disclaimer text migrated into images, why traditional text-based scanning cannot see it, and how a rendered-view plus OCR approach checks what the recipient actually sees. It finishes with a practical, repeatable setup you can run before every send — and how RuleRun automates the whole loop.
Why required text keeps ending up inside images
Marketing teams do not embed legal text in images to hide it. It happens as a side effect of how modern email creatives are produced. Understanding the “why” matters, because it tells you where to look during review.
- Design control.Email clients render HTML and CSS inconsistently. A designer who needs a pixel-perfect banner — custom fonts, precise kerning, a disclaimer tucked into a corner — often flattens the whole creative into a single image to guarantee it looks identical everywhere.
- Brand and campaign assets.Hero images, promotional banners and seasonal creatives arrive from design tools or agencies as finished artwork. The “18+” badge or the risk warning is baked into that artwork before it ever reaches the email builder.
- Web fonts and rendering fallbacks. To keep a specific typeface for a disclaimer, teams rasterize the text so it does not silently fall back to a default font that changes its size or legibility.
- Reuse across channels. The same banner is dropped into email, in-app messages and paid social. Whatever legal text was burned into the image for one channel travels with it into the inbox.
The result is predictable: the words a regulator cares about are present to a human reader but absent from the HTML. A reviewer skimming the rendered email sees the disclaimer and ticks the box. A tool parsing the markup sees nothing at all.
Why source-code and text scanners miss it entirely
Most compliance and content tools operate on the email’s underlying text: the HTML body, the plain-text alternative, alt attributes and link targets. That is the correct place to look for a live text disclaimer. It is exactly the wrong place to look for one baked into a JPEG or PNG.
What a text-based scan can and cannot see
- Can see: HTML copy, plain-text parts, alt text, link URLs, tracking parameters, hidden preheader text.
- Cannot see: any word rendered as pixels inside an image — the badge, the banner caption, the fine print flattened into artwork.
Alt text is a tempting shortcut, but it is not a reliable compliance surface. It is optional, frequently empty or auto-generated, often does not match the visible wording, and is ignored by many clients that simply show the image. Treating alt text as proof that a disclaimer is present is how a missing warning slips through review.
A green checkmark can be a false negative
A source-code scanner reporting “no issues” on an image-heavy email is not confirming compliance — it may simply be blind to the pixels where your disclaimer lives. Absence of a flag is not the same as presence of the required text.
Rendered view plus OCR: checking what the recipient sees
To check image-embedded text you have to stop reading the email and start looking at it. That means two steps working together: render the email the way an inbox would, then run optical character recognition (OCR) across the resulting pixels to recover the words a human would read.
- Render first.Compose the full email — HTML, remote images, fonts — into an actual visual layout, the same picture the recipient opens. This produces a faithful screenshot rather than a tree of tags.
- OCR the rendered pixels.Run text recognition over the rendered image, including every embedded creative. OCR returns the recognized words along with their position, so you know not just that “18+” exists but where on the page it sits.
- Match against policy. Compare the recovered text against your list of required phrases, allowing for normal formatting variation, then flag anything missing.
This is the core idea behind how RuleRun evaluates a creative: it works from the rendered view, so text inside an image is treated exactly like text in the HTML body. If a recipient can read it, the check can read it too.
A step-by-step image-text compliance check
The mechanics are the same whether you run them manually before a send or wire them into an automated pipeline. Follow these five steps in order.
- 1. Define the required phrases.Write down the exact strings your policy demands — “18+”, “BeGambleAware”, “T&Cs apply”, “Capital at risk” — and note where each must appear and any localized variants.
- 2. Render the email. Generate a faithful rendered view including remote images and web fonts, so every banner and badge is present exactly as a recipient would receive it.
- 3. OCR every image. Recognize text across the full rendered creative, not just the HTML. Capture recognized words and their positions so you can reason about prominence later.
- 4. Match phrases with tolerance.Compare recovered text against your required list, allowing for case, spacing, punctuation and common OCR substitutions — but not so loosely that a wrong phrase passes for a right one.
- 5. Flag misses with evidence. For anything not found, produce a clear finding tied to a screenshot, so a reviewer can act rather than re-inspect the whole email by hand.
Store the phrases as policy, not as tribal knowledge
Keep the required-phrase list in a versioned rule set rather than in a reviewer’s head. When a regulator updates wording, you change it once and every future campaign is checked against the new language automatically.
Common pitfalls that break naive image-text checks
Rendering and OCR solve the visibility problem, but real creatives introduce failure modes that a careless check will trip over. Watch for these.
- Low contrast.Pale grey fine print on a white background, or white text on a light photo, confuses both OCR and human eyes. If a check can barely read it, a regulator may argue a recipient cannot either — a prominence problem, not just a recognition one.
- Tiny font sizes. Disclaimers shrunk to fit a corner drop below the resolution OCR needs. Render at a high enough resolution, and treat sub-legible text as a finding in its own right.
- Truncation and cropping.Responsive layouts and client-specific scaling can crop a banner so the disclaimer is pushed off the visible edge — present in the source image, invisible in the inbox.
- Text over busy backgrounds.Warnings placed over a photograph or gradient lose their edges, causing dropped characters. “BeGambleAware” becoming “BeGamb1eAware” must still match.
- Localized variants. A campaign sent across markets swaps the disclaimer per language. Your required-phrase list has to account for each locale, or the German send passes on an English rule.
Fuzzy matching, within reason
Allow for predictable OCR noise — a “1” read as an “l”, an extra space, a dropped ampersand. But keep the tolerance tight enough that a genuinely different or incomplete phrase is still flagged. The goal is to forgive recognition artifacts, not to forgive missing text.
Concrete examples: iGaming and financial promotions
The two regulated verticals where image-embedded compliance text bites hardest are iGaming and financial promotions. The specifics differ, but the failure pattern is identical.
iGaming creatives
- “18+” — the age gate, almost always rendered as a small badge inside the banner artwork.
- “BeGambleAware” — the responsible-gambling reference, frequently a logo lockup with the wordmark burned in as pixels.
- “T&Cs apply” — the terms reference tucked under a promotional offer, often at a font size that stresses OCR.
Financial promotions
- “Capital at risk” — the core risk warning, commonly overlaid on a hero image of a product or chart.
- Risk and past-performance disclaimers — longer fine print flattened into the creative so the layout stays fixed across clients.
In every one of these cases, an HTML-only scan reports a clean bill of health while the required wording sits entirely inside a picture. Only a rendered-view check that reads pixels — the approach RuleRun takes — can confirm the disclaimer is genuinely there and genuinely legible.
Every image
OCR runs across each creative, not just the HTML body
Seconds
A full rendered-view check completes in the time a manual review just gets started
100%
Of required phrases matched against the rendered view a recipient actually sees
How RuleRun automates this end to end
Doing all of this by hand — rendering, reading every badge, cross-checking each phrase per locale — is slow and easy to get wrong under deadline pressure. RuleRun runs the entire loop automatically for every campaign before it goes out.
- Renders the real email, pulling remote images and fonts so the check sees what the inbox sees.
- OCRs every embedded image, recovering text from banners, badges and flattened fine print alongside the HTML copy.
- Matches your required phrases from a versioned rule set, with tolerance for OCR noise and support for localized variants.
- Checks prominence and legibility, not just presence — flagging text that is too small or too low-contrast to count.
- Validates links and assets in the same pass, so image-text is one part of a complete pre-send check.
- Produces screenshot and PDF evidence, giving reviewers an auditable record of exactly what was found and where.
If a recipient can read it, RuleRun can check it.
Rendered-view OCR finds required disclaimers wherever they live — HTML text or baked into a banner — and backs every finding with screenshot and PDF evidence.
Key takeaways
- Required legal, age-gate and risk-warning text increasingly lives inside banner images, not in HTML text.
- Source-code and text-based scanners cannot see pixels, so image-embedded disclaimers pass unchecked; alt text is not reliable proof.
- Rendered view plus OCR reads the words a recipient actually sees, treating image text the same as HTML text.
- Run five steps: define required phrases, render, OCR every image, match with tolerance, flag misses with evidence.
- Watch for low contrast, tiny fonts, cropping, busy backgrounds and localized variants that break naive checks.
- RuleRun automates the full loop end to end and produces screenshot and PDF evidence for every run.