Why Gmail is Stripping Inline Images

When Gmail strips inline images, the recipient sees broken image icons, empty whitespace, or displaced attachments instead of the intended visual design. This occurs because Gmail does not render images directly from external servers or local drives. Instead, it routes all images through a secure proxy server and enforces strict HTML parsing rules. Understanding how the Gmail Image Proxy handles Base64 data URIs, Content-ID (CID) MIME headers, and SSL certificates allows administrators and developers to keep message layouts intact.

Why Gmail Strips Images and How to Fix It

Gmail strips inline images when they are embedded using Base64 data strings (which Gmail blocks for security), when Content-ID (CID) headers in multipart MIME emails are misconfigured, or when the Gmail Image Proxy cannot fetch the image due to broken SSL certificates or restrictive firewalls. To fix this, host images externally on a publicly accessible HTTPS server and reference them using standard <img src="https://..."> tags.

How Gmail Processes Images: The Proxy Architecture

In 2013, Google changed how Gmail renders images. Instead of allowing a recipient’s browser to make direct HTTP or HTTPS requests to the host server where an image lives, Google routes all image requests through a dedicated caching proxy:

Sender Email Client
        │
        ▼
HTML Message Body: <img src="<https://assets.example.com/logo.png>">
        │
        ▼
Delivered to Recipient's Gmail Account
        │
        ▼
Gmail Web / Mobile Client Requests Image
        │
        ▼
Google Image Proxy (googleusercontent.com)
        │
        ├── 1. Fetches image from: <https://assets.example.com/logo.png>
        ├── 2. Scans image for security threats / malware
        ├── 3. Resizes, converts, and caches image on Google servers
        │
        ▼
Rendered in Browser as:
<img src="<https://ci3.googleusercontent.com/proxy/abc123xyz>...">

This proxy architecture provides security by hiding the recipient’s IP address, blocking tracking cookies, and preventing malicious scripts from executing. However, if the Google Image Proxy encounters an error while fetching the image, or if the email’s code violates Gmail’s HTML standards, the image fails silently and renders as a broken icon.

Primary Causes of Stripped or Broken Images

1. Using Base64 Data URIs Instead of Hosted URLs

Many developers and automated mail scripts embed images directly into the HTML body using Base64 encoding strings:

<!-- Gmail actively blocks or strips this format -->
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...">

Gmail’s web interface routinely strips or ignores Base64 data strings inside <img> tags. Google enforces this to maintain browser rendering speed and prevent message size bloat. Large Base64 strings can also push the total message size over Gmail’s 102 KB HTML clipping limit. For more details on the data size penalties that come with embedded assets, review Why Your 25MB Attachment Failed (Encoding).

2. Google Image Proxy Cannot Reach the Host Server

If your images are hosted externally, the Google Image Proxy must be able to download them over the public internet. If the proxy fails to fetch an image, it strips the image from the message. Common failure points include:

• Local or Staging URLs: Referencing private, internal URLs (e.g., http://localhost/logo.png or http://192.168.1.50/image.jpg).
• Broken SSL/TLS Handshakes: If the image server has an expired, self-signed, or improperly chained SSL certificate, the Google proxy terminates the connection.
• Firewall and Bot Blocking: If your web server or Web Application Firewall (WAF, such as Cloudflare or AWS CloudFront) blocks requests from Googlebot or Google’s proxy user-agents, the image proxy returns an HTTP 403 or 404 status.
• HTTP to HTTPS Redirect Chains: If the image link uses an insecure HTTP URL that redirects multiple times to an HTTPS destination, the proxy may drop the request after an SSL timeout.

3. Misconfigured Content-ID (CID) in Multipart MIME Emails

When an email client sends an inline image directly inside the message payload rather than linking to a web address, it must format the email as a multipart/related MIME message.

The HTML references the image using a CID:

<img src="cid:companylogo_01">

The image must then be included as an attached MIME part with matching headers:

Content-Type: image/png; name="logo.png"
Content-Transfer-Encoding: base64
Content-ID: <companylogo_01>
Content-Disposition: inline; filename="logo.png"

If the angle brackets (< >) are omitted from the Content-ID header, if the identifier inside the HTML does not match the MIME boundary, or if the attachment is marked as Content-Disposition: attachment instead of inline, Gmail will detach the image and display it as a generic attachment at the bottom of the email.

4. Unsupported Image Formats

The Google Image Proxy converts and optimizes common image formats (JPEG, PNG, GIF, and WEBP). However, it does not support:

• Scalable Vector Graphics (.svg): SVG files are XML-based and can execute embedded JavaScript, so Gmail strips them to protect users from Cross-Site Scripting (XSS) attacks.
• Tagged Image File Format (.tiff): TIFF files are not supported natively by modern web engines and fail to render through the proxy.
• High Efficiency Image File (.heic): HEIC files sent directly from mobile devices often fail to parse unless converted to JPEG prior to transmission.

5. Compliance Rules and Message Footers

In corporate environments, administrators sometimes create rules that inadvertently strip inline assets. Review your settings against Fix: “Content Compliance” Rule Blocking Mail to confirm that outbound content scanners are not modifying MIME boundaries or removing embedded media.

Diagnostic and Remediation Steps

Step 1: Inspect the Proxy URL in the Recipient Browser

Open the affected email in the Gmail web interface using Google Chrome:

1. Right-click the broken image placeholder and select Inspect.
2. Examine the src attribute. It will look like this:
   https://ci3.googleusercontent.com/proxy/[LongHashString]=s0-d-e1-ft#<https://yourdomain.com/image.png>
3. Look at the end of the proxy URL (after the # symbol). This displays the exact original URL Google tried to reach.
4. Copy the original URL, paste it into an incognito browser window, and confirm:
   • Does the image load without requiring a login?
   • Does the SSL padlock show a valid, trusted certificate?
   • Does the server return a clean HTTP 200 OK response with a valid Content-Type: image/png or image/jpeg header?

Step 2: Use Absolute HTTPS Paths on a Public CDN

Never use relative paths (/images/logo.png) or data URIs. Host your email assets on a content delivery network (CDN) like Amazon S3, Cloudflare R2, or Google Cloud Storage, and verify that the bucket permissions are set to public read.

<!-- Correct Implementation -->
<img src="<https://cdn.example.com/assets/email-logo.png>"
     alt="Company Logo"
     width="200"
     height="50"
     style="display: block; border: 0;">

Step 3: Prevent Image Clipping from Message Bloat

If your HTML template contains too much text, code, or inline formatting, Gmail clips the email after 102 KB and displays a notice stating: [Message clipped] View entire message. Any images referenced below that cutoff point will not render until the user clicks the expansion link. Keep your raw HTML file size under 100 KB.

If you need to distribute large, high-resolution media that exceeds standard transmission safety margins, review Troubleshooting “Message too large” (Inbound/Outbound) and consider hosting files externally using How to Fix Google Drive Link Permissions in Gmail.