Ever looked at an email's HTML source and seen a long string of random characters after "data:image"? That's base64 encoding. But what is it, and should you use it in your emails?
Here's what you need to know about base64 encoding images in emails, including when to use it and when to avoid it.
Base64 is a method of encoding binary data like images into ASCII text characters. This lets you embed images directly into HTML and CSS files as text strings, rather than linking to external files.
When you base64 encode an image, it converts the image file into a long string of letters, numbers, and symbols:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...
This encoded string can be used directly in an <img> tag's src attribute or in CSS as a background image.
In email marketing, base64 encoding lets you embed images directly into the email's HTML rather than hosting them on a server.
Here's the difference:
Traditional image embedding:
html
<img src="https://yourdomain.com/images/logo.png" alt="Logo">
Base64 encoded image:
html
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA..." alt="Logo">
With base64 encoding, the entire image lives within the email HTML itself.
Many email clients block external images by default for privacy and security. With base64 encoded images, the image is part of the email itself, so it displays immediately without requiring the recipient to "download images."
You don't need to host images on a web server or CDN. Everything is self-contained within the email, which simplifies deployment and eliminates broken image links.
Since the image data is embedded in the email, recipients can view the images even without an internet connection (as long as they've downloaded the email).
The email client doesn't need to make additional HTTP requests to fetch images, which can marginally improve loading speed.
Base64 encoding increases the file size of your images by approximately 33%. A 100KB image becomes 133KB when encoded. This bloats your email size, which can:
One of the biggest drawbacks is that you lose the ability to track email opens. Most email tracking works by embedding a tiny, unique image (tracking pixel) in each email. When the recipient's email client downloads that image from your server, it registers as an "open."
With base64 encoded images, there's no external request made, so no tracking data is captured.
Some email clients still handle base64 images poorly or don't support them at all:
Outlook desktop versions have historically had issues with base64 images. Gmail clips messages over 102KB, and base64 encoding can quickly push you over this limit. Some mobile email clients may struggle with large embedded images.
Once the email is sent, the base64 encoded image is permanent. If you need to update an image (fix a typo, change pricing), you can't do it.
With externally hosted images, you can swap out the image file and all emails will show the updated version.
Large emails with heavily encoded content can trigger spam filters. The unusual encoding patterns may look suspicious to some filtering systems.
Base64 encoding makes sense in these scenarios:
For tiny images that are essential to your email (like a small logo or icon that must display), base64 can ensure they always show up. Keep these under 5-10KB.
If you're sending transactional emails (receipts, password resets) where tracking isn't needed and you want to ensure brand elements always display, base64 can work well.
For personal email signatures where you want a small logo or headshot to always appear, base64 encoding can be effective.
Avoid base64 encoding in these cases:
If you need to track opens, clicks, and engagement, stick with externally hosted images. The tracking capability is far more valuable than the minor convenience of base64.
Never base64 encode large images (photos, banners, product images). The file size bloat will hurt deliverability and user experience.
For content-rich newsletters with several images, base64 encoding will make your email massive and likely to be clipped by Gmail or flagged by spam filters.
If a significant portion of your audience uses Outlook desktop clients, base64 images may not render correctly.
If you decide to use base64 encoding, follow these guidelines:
Only encode images under 10KB. Limit to 1-2 small images per email maximum. Optimize and compress images before encoding.
Test rendering across all major email clients. Keep total email size under 100KB to avoid Gmail clipping.
Always include descriptive alt attributes for accessibility. Consider including a plain text version of your email.
If you want to experiment with base64 encoding, here are a few methods:
Numerous free online tools will convert images to base64. Simply upload your image and copy the resulting code.
base64 -i image.png -o output.txt
// In Node.js
const fs = require('fs');
const imageBuffer = fs.readFileSync('image.png');
const base64Image = imageBuffer.toString('base64');
import base64
with open("image.png", "rb") as image_file:
encoded = base64.b64encode(image_file.read())
Base64 encoding images in emails is a double-edged sword. While it can ensure certain images always display and eliminates the need for external hosting, it comes with significant drawbacks: larger email sizes, no tracking capability, and inconsistent support across email clients.
The verdict: For most email marketing campaigns, externally hosted images are the better choice. Reserve base64 encoding for small, critical images in transactional emails where tracking isn't needed.
Testing is key. If you're considering base64 encoding, run A/B tests to see how it impacts your deliverability, rendering, and overall campaign performance. Your specific audience and email client distribution will determine whether base64 encoding is right for you.
Are your email subjects marking you as spam?
Are you being filtered as a 'Promotion' instead of a 'Priority'?
Find out instantly.