How do images get displayed (linked vs. embedded)?

When you add an image to an email, you have two options: linked images (hosted externally and referenced by URL) or embedded images (included directly in the email file itself). Which one you choose affects how reliably the image displays, how your email loads, and what happens when someone forwards it.

Linked images work like this: your email contains an HTML <img> tag with a URL pointing to where the image lives (your server, a CDN, your ESP's image hosting). When the recipient opens the email, their email client makes a separate HTTP request to fetch that image. If the image server is down, the link breaks, or the recipient's email client blocks external images (which most do by default), the image won't display. Instead, they'll see a broken image icon or the alt text you specified.

The advantage: linked images keep your email file size small, which helps with deliverability (large emails are more likely to bounce or get truncated). The tracking pixels ESPs use to record opens are linked images. One-pixel transparent GIFs hosted on the ESP's server. When your email client loads that image, the ESP knows you opened the email.

The disadvantage: if the recipient forwards your email to someone else, those images might not load anymore (depends on whether the image URL is publicly accessible or tied to a specific recipient token). And if your image hosting goes down, every email you've ever sent with those images will show broken image icons.

Embedded images work differently. The image file gets encoded (usually with Base64 encoding) and included directly in the email's MIME structure, in the same way attachments get encoded. The email references the image with a cid: (Content-ID) URL instead of an HTTP URL. Because the image travels with the email, it'll display even if the recipient is offline or if external image loading is blocked.

The advantage: embedded images are self-contained. Forward the email, the image goes with it. No dependency on external servers. Great for transactional emails (receipts, invoices) where you want the image to display reliably no matter what.

But the disadvantage: embedded images increase your email's file size, sometimes significantly. If your email gets too large (over 100KB is a common threshold), some email clients will clip it or some spam filters will flag it. Gmail clips emails over 102KB, hiding everything after that point behind a "View entire message" link. And embedded images don't help with tracking, you can't tell when someone opened the email by looking at image requests.

When to use which: Marketing emails and newsletters almost always use linked images. You want tracking, you want to keep file size down, and you're okay with the trade-off that some recipients won't see the images immediately (they'll have to click "Load images" or whitelist your sender). Transactional emails (password resets, receipts, shipping notifications) often use embedded images for logos or critical branding, because you want those to display no matter what. But even then, keep it minimal. One small logo embedded, everything else linked or plain text.

Most ESPs default to linked images and handle the hosting for you. If you're sending from Postmark or Customer.io, they'll host your images on their CDN and automatically handle the <img> tags. If you're coding your own HTML and sending through AWS SES or Mailgun, you'll need to host images yourself (or use a service like Cloudinary or Imgix) and reference them by URL.

One more thing: if you're embedding images, test your email's total file size. Most email clients won't complain until you hit 100KB+, but if you're embedding multiple high-res images, you'll get there fast. Compress your images first (TinyPNG, Squoosh, whatever you prefer), and keep embedded images under 50KB each if you can.

If you're unsure which method your ESP is using, check the raw email source with our Source Analyzer. Look for <img src="http://..."> (linked) or <img src="cid:..."> (embedded).