Why does Gmail remove Base64 images from email?

Gmail sanitizes inbound HTML and blocks data: URIs in img tags as a security measure — embedded payloads can hide arbitrary content. The result is a blank area where the image was, with no fallback unless you provide alt text or a second rendering path.

When is a Base64 data URI the right choice in email?

When the recipients are known to use permissive clients (Apple Mail, Thunderbird), when no hosting or attachment API is available, or when zero-upload handling matters — internal tools generating mail from images that must not touch a server. Always ship alt text, because a large share of the audience will see it instead.

How much bigger does a Base64 image make the email?

About a third larger than the binary file, since Base64 encodes three bytes into four characters. A 300 KB logo becomes a 400 KB string inside the HTML — and every recipient downloads that weight on every send. Keep embedded images small and check them with a size calculator first.

Do email signature images work as data URIs?

Partially. Gmail enforces a signature size limit of about 10,000 characters, which a small Base64 logo can exceed on its own, and Outlook's desktop signature editor rejects them. Apple Mail signatures handle data URIs fine. The safe cross-client pattern remains a small hosted image.

Base64 images in HTML email: what renders and what gets stripped

Q: What is the reliable way to embed an image in email?

Two proven paths: a hosted image referenced by absolute HTTPS URL (works nearly everywhere, at the cost of a remote request), or a CID inline attachment — raw Base64 in the attachments structure with a Content-ID, referenced from the HTML as cid:name. Both survive Gmail and Outlook.

You encoded a logo to a data URI, dropped it into an <img> tag, sent the test email — and half your test inbox shows a blank box. This guide explains which clients render Base64 data URIs, which strip them, and which of the three embedding paths (data URI, CID attachment, hosted URL) to use where, with the working pattern for the transactional APIs most developers actually send through.

Three ways an image travels in email

Everything that looks like an "embedded image" in email is one of three mechanisms, and mixing them up is the root of most blank-image bugs:

Mechanism	How it works	Reliability
Hosted URL	`<img src="https://cdn.example.com/logo.png">` — the HTML references a file on your server. The client downloads it when the recipient allows remote images.	Highest. Renders in every modern client once images are enabled; you control the bytes, and swapping the file updates all sent mail.
CID attachment	The image rides in the MIME structure as an attachment with a `Content-ID`; the HTML references it as `<img src="cid:logo">`. No external request, no paperclip icon when `Content-Disposition` is `inline`.	High. Survives Gmail and Outlook desktop. Requires the sending path to support MIME attachments — i.e. an API or library, not a paste-into-editor workflow.
Data URI	The bytes sit inside the HTML itself: `<img src="data:image/png;base64,iVBOR...">`. Fully self-contained, zero requests, zero server involvement.	Partial. Rendered by Apple Mail, Thunderbird and Yahoo Mail; stripped by Gmail; not rendered by Outlook on Windows. Works where it works, and silently disappears where it does not.

The data URI's privacy property is real and worth having: the image is processed and embedded without ever touching a server. The rest of this guide is about where that property survives delivery.

Client-by-client support matrix

Client behavior is consistent enough to plan around, and two clients cause essentially all the pain:

Client	Data URI in `<img>`	What actually happens
Gmail (web, Android, iOS)	❌ Stripped	The sanitizer removes data URIs from `src` before rendering — the image area is blank. No workaround in the HTML itself.
Outlook (Windows desktop)	❌ Not rendered	The Word rendering engine does not display data URIs in message bodies. Blank box or broken-image glyph.
Outlook.com / new Outlook	⚠️ Inconsistent	Behavior varies by version and sanitize path; do not rely on it.
Apple Mail (macOS, iOS)	✅ Renders	Data URIs display normally, including in signatures.
Thunderbird	✅ Renders	Displays data URI images in message bodies.
Yahoo Mail	✅ Generally renders	Data URIs display, though image blocking on remote content does not apply — the URI is already in the message.

Two consequences follow from the two red rows. First, a data URI must never be the only copy of an image in anything sent to unknown recipients — always ship meaningful alt text. Second, if the audience is Gmail-and-Outlook-heavy (which is most B2B audiences), choose hosted or CID from the start instead of debugging stripped images afterwards.

When the data URI is actually the right call

The matrix is not an argument against data URIs — it is an argument for matching the mechanism to the audience:

Known-permissive audiences. Internal tools, admin dashboards, or workflows where you know recipients live in Apple Mail or Thunderbird render fine.
Zero-upload requirements. A tool that turns a user's screenshot into a draft email can embed it as a data URI without uploading the image anywhere — the property this site's converters are built around. The image only travels with the mail itself.
Self-contained archives. A rendered-to-HTML receipt or report that must stay intact as a single file, offline, years later, has no better option. The same logic as embedding images in a single HTML file.
Progressive enhancement. Sending both a data URI and a hosted fallback is possible (nested or conditional markup is fragile), so in practice: pick per audience, and keep alt text honest.

Working patterns per provider

Transactional APIs give you the MIME level, which is where CID attachments live. Each of these has a dedicated guide with full payloads:

SendGrid — raw Base64 in the attachments array, content_id you choose, disposition: "inline", and cid: in the HTML. Data URIs in the HTML get stripped. → SendGrid inline image with Base64
Postmark — same shape: Attachments[].Content is raw Base64 and Attachments[].ContentID follows the cid: format that the HTML references. → Postmark inline image with Base64
Brevo — the public transactional /smtp/email schema documents attachments as Base64 but exposes no Content-ID field, so inline-via-CID is not available on that endpoint today; for inline visuals use a hosted URL. → Brevo attachments without CID
Power Automate — the Compose + base64() pattern builds the string, but the Office 365 connector's mail target still strips data URIs, so the result needs the attachment path. → Power Automate Base64 image in email
Google Apps Script — GmailApp rejects data URIs in HTML bodies; decode to a blob and pass it via inlineImages with a cid: reference. → Apps Script Base64 image in email
Excel VBA / Outlook automation — Outlook object model needs the hidden-attachment CID pattern, since Word-engine rendering rejects data URIs. → Excel VBA Base64 image in Outlook email

The mechanism behind every bullet is the same one: when the target is Gmail or Outlook, move the image out of the HTML and into the MIME structure (CID) or onto a server (hosted URL).

Size math and message limits

Base64 encodes three bytes into four characters — about a 33% overhead — and in email that weight lands on every recipient, in every mailbox, on every send:

A 200 KB hero image becomes a ~270 KB string inside the HTML. Five images and the message body alone approaches a megabyte before any text.
Mail providers cap message size (commonly in the 25 MB range, lower per recipient server), and a bloated HTML body eats that budget before attachments are counted.
Gmail signatures have their own, much tighter ceiling of roughly 10,000 characters — see the signature section.
Downscale to the rendered size first (a 1200 px logo shown at 120 px wastes 99% of its bytes), then encode. The resize guide and the Base64 size calculator handle both halves.

The signature special case

Signatures deserve their own caution because they fail differently from campaigns:

Gmail caps the whole signature near 10,000 characters. A small Base64 logo alone can run 8,000+ characters, so pasting a data URI signature either fails to save or silently truncates. Gmail's editor accepts uploaded or hosted HTTPS images instead. → Gmail signature Base64 not working
Outlook desktop builds signatures through the Word engine and does not render data URIs there; the reliable path is a small hosted image in the signature HTML. → Base64 image not showing in Outlook
Apple Mail handles data URI signatures well — one of the few places the self-contained form genuinely shines. → Base64 image in email signature

Frequently asked questions

Do Base64 data URI images work in HTML email?

Only in some clients. Apple Mail, Thunderbird and Yahoo Mail render them; Gmail strips them from the HTML and Outlook on Windows does not display them. Treat a data URI as a progressive enhancement for a known-permissive audience, with real alt text behind it.

Why does Gmail remove Base64 images?

Gmail sanitizes inbound HTML and blocks data: URIs in img tags as a security measure, so the image area renders blank. There is no markup-level workaround — the image has to arrive by another mechanism.

What is the reliable way to embed an image in email?

A hosted HTTPS image (works everywhere images are enabled) or a CID inline attachment (raw Base64 in the MIME structure referenced as cid:name). Both survive Gmail and Outlook desktop.

When is a data URI the right choice?

When recipients are known to use permissive clients, when no hosting or attachment API is available, or when zero-upload handling is the point — internal tooling that must not send user images to any server. Always ship alt text.

How much bigger does Base64 make the email?

About a third. A 200 KB image becomes a ~270 KB string that every recipient downloads on every send. Downscale to rendered size, encode, and verify with a size calculator.

Do signature images work as data URIs?

Apple Mail: yes. Gmail: the ~10,000-character signature limit usually rejects them first. Outlook desktop: the Word engine does not render them. Cross-client safe means a small hosted image.

Where can I encode an image without uploading it?

The image to Base64 converter and the data URI generator on this site run entirely in the browser — the file is read locally with the FileReader API and never leaves the device.