Your signature logo or photo shows as a red X, a broken-image placeholder, or shows blurry on Retina. Here's why mail clients drop signature images and how to fix each cause.
The MailSigCraft Team
MailSigCraft
You set up an email signature with a clean logo, sent a test, and the recipient saw a red X, a "Click here to download pictures" bar, a broken-image icon, or a giant blurry version of your logo. The signature itself is fine — the image is the part that broke. Mail clients treat embedded images differently from web browsers, and there are seven specific reasons your signature image fails to render.
This post walks through each cause in roughly the order we see it happen, with the exact fix for each. The post covers Gmail (web + mobile), Outlook (classic desktop + new Outlook + on the web), and Apple Mail (macOS + iOS).
If your signature <img src="..."> points at a private CDN, an intranet URL, a localhost path, or an internal SharePoint link, the recipient's mail client tries to fetch it and gets a 403 or a connection timeout. The image renders fine in your own preview because your laptop is on the network — the recipient's laptop isn't.
Host the image somewhere publicly reachable over the open internet. Imgix, Cloudinary, Cloudflare R2, S3 with public-read, or the MailSigCraft editor (which uploads to a public CDN automatically) all work. Open the image URL in an incognito browser window — if you can see it there, the recipient can see it in their mail client.
Some image hosts — Google Drive, Dropbox, OneDrive, and most CMS systems — serve images with a Referer check or send Content-Disposition: attachment headers that mail clients refuse to inline. The URL works in a browser tab and breaks in an email signature.
Never use a file-sync service URL (drive.google.com, dropbox.com/s/..., onedrive.live.com) as an <img src>. These are designed for human download, not for image embedding. Use a dedicated image host instead — Cloudinary, imgix, GitHub Pages, or a CDN. If you're stuck with Google Drive, switch to the format https://lh3.googleusercontent.com/d/<file_id> — Google's image-serving subdomain doesn't block hotlinking the way drive.google.com does — but a real CDN is more reliable.
<img src="/logo.png"> or <img src="logo.png"> resolves correctly in a web browser because the browser knows what page it's on. Mail clients don't have a "current page" — they need a fully-qualified URL.
Every <img src> in a signature must start with https://. Run a find-and-replace on your signature HTML for src="/ and src="./ — both are signs of relative paths that won't survive being pasted into Gmail or Outlook.
Modern Gmail, Outlook, and Apple Mail silently strip mixed-content images. If your signature loads over HTTPS (which it always does in the web Gmail UI) and the image URL is http://, the image is blocked client-side as a mixed-content security risk. The recipient sees either a broken-image placeholder or nothing at all.
Every signature image URL must be https://. If your image host doesn't support HTTPS in 2026, change hosts — there's no acceptable production setup without it.
This is the most common "works for me, broken for them" case. Classic Outlook for Windows treats external images as a privacy risk and blocks them by default, showing "Click here to download pictures" or a red X. The image is reachable; Outlook is refusing to fetch it without permission.
<img src="data:image/png;base64,..."> embeds the image data into the HTML directly, so there's no external request for Outlook to block. Tradeoff: base64 eats Gmail's 10,000-character signature budget fast.Cache-Control: public, max-age=... header and proper Access-Control-Allow-Origin survive Outlook desktop's image-download prompt for senders the recipient has corresponded with before.The cross-client compatibility post covers the trade-offs in more depth.
If your logo looks crisp on Windows and pixelated on a Mac, iPhone, or iPad, the cause is Retina display rendering. Apple Mail (macOS + iOS) and modern Gmail iOS render images at native pixel size by default. A 100×100 logo intended for 50px display shows up at 100×100 on a non-Retina screen and at a blurry 50×50 on Retina because the device renders it at half its pixel size.
Export the source image at 2× the display size, then set explicit width="" and height="" attributes at 1× on the <img> element. So for a 50px-tall logo, export a 100×100 PNG and use <img src="..." width="50" height="50">. The browser/mail client downscales the high-res source on standard displays and uses the full resolution on Retina — sharp everywhere.
If you're using base64 inlining (see #5) and the image looks washed out or blocky, it's a compression issue. PNG-24 is lossless but big; PNG-8 is small but only 256 colors and can crush gradients; JPEG is small but adds halo artifacts around hard edges like logo lettering.
For a logo with hard edges (typography, geometric shapes), use PNG-24 with tinypng or squoosh lossy optimization — keeps edges crisp, cuts file size by 60–80%. For a photo (avatar headshot, banner), use JPEG quality 80 — smaller than PNG and the JPEG artifacts are invisible in photos. Avoid PNG-8 for logos with any gradient or shadow; you'll see banding.
Open every image URL in an incognito browser tab — does it load?
Confirm each URL starts with https:// — never http://.
Confirm each URL is absolute — never starts with / or ..
Each <img> has explicit width="" and height="" attributes.
The MailSigCraft editor handles all six of these by default — uploaded images go to a public CDN over HTTPS with proper headers, the rendered HTML uses absolute URLs with explicit width/height attributes, and small assets are base64-inlined automatically when it fits the budget. The output paste-tests across Gmail, Outlook desktop, Outlook web, Apple Mail, and the iOS Mail app without changes.
Source images are exported at 2× the display size.
For Outlook compatibility, small icons are base64-inlined; larger logos hosted on HTTPS with caching headers.