Image to Base64 Converter

What Is Base64 Encoding?

Base64 encoding converts binary data — such as the raw bytes that make up an image file — into a string of printable ASCII characters. It uses 64 characters: A–Z, a–z, 0–9, plus + and /, with = for padding. Every three bytes of binary input become four Base64 characters, so Base64 output is always about one-third larger than the original binary data.

Base64 is not encryption — it is encoding. Anyone can decode it instantly with a single function call. Its purpose is to allow binary data to travel safely through text-only channels: HTML attributes, CSS url() functions, JSON payloads, and email systems that were originally designed to carry only 7-bit ASCII text.

Originally developed for email attachments in the 1980s, Base64 today appears throughout web development wherever binary data needs to be embedded in or transmitted through text-based formats. You will encounter it in JWT tokens, CSS sprites, inline SVG, canvas.toDataURL() output, and many REST API responses.

How a Base64 Data URL Works

A data URL is a special URL scheme that encodes file contents directly inside the URL string, rather than pointing to a separate server resource. The format is:

data:[MIME_TYPE];base64,[BASE64_STRING]

For a PNG image this looks like:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAAB...

The browser treats a data URL exactly like a regular URL — you can use it as an <img> tag's src attribute, a CSS background-image: url(), a <canvas> draw source, or anywhere else that accepts an image URL. No network request is made because the entire image is encoded in the string itself.

This tool gives you four ready-to-use output formats. The Data URL tab gives you the complete data:... string. Base64 String gives you just the encoded characters after the comma — useful when an API or library expects raw Base64. CSS gives you the full background-image property, and HTML gives you a complete <img> tag.

When to Use Base64 Images

Embedding an image as Base64 makes sense in several specific scenarios:

Small icons and UI elements

For images smaller than 2–5 KB, the cost of the additional HTTP request to fetch a separate file (round-trip latency, DNS lookup, TCP handshake, TLS negotiation) often exceeds the cost of the 33% size increase from Base64 encoding. Tiny icons, favicons, loading spinners, and simple logos are ideal candidates for inlining.

HTML email templates

Many email clients — Outlook, Gmail on some views, Apple Mail in certain configurations — block externally hosted images by default. They show a placeholder until the user clicks "load images." Base64 data URLs bypass this entirely: the image is embedded directly in the HTML, so it appears immediately without requiring the recipient to download anything from your server. This is the most reliable way to guarantee image display in transactional emails, newsletters, and email receipts.

Single-file HTML pages and offline apps

When you need to distribute a completely self-contained HTML file — a shareable report, an offline dashboard, a standalone tool — Base64 images let you bundle every visual asset directly into the HTML. The recipient can save the file locally and open it with no internet connection, and every image renders perfectly.

Preventing mixed-content warnings

On HTTPS pages, browsers block requests to HTTP (non-secure) image sources and show mixed-content warnings. If you need to include an image from an HTTP-only source, converting it to Base64 and embedding it directly is a clean way to eliminate the warning without hosting the image yourself over HTTPS.

Canvas and JavaScript data manipulation

When processing images in a <canvas> element and then exporting the result with canvas.toDataURL(), you are already working with Base64. Passing a Base64 string between steps — loading, filtering, exporting — is often more straightforward than creating and revoking Object URLs, particularly in complex pipelines.

How to Embed Base64 in CSS

The CSS output tab of this tool gives you a ready-to-paste background-image property. Drop it inside any CSS rule:

.hero {
  background-image: url('data:image/png;base64,iVBORw0KGgo...');
  background-size: cover;
  background-repeat: no-repeat;
}

CSS supports Base64 data URLs everywhere a URL is accepted: background-image, list-style-image, border-image, and content for pseudo-elements. This makes it possible to embed decorative assets — bullet icons, divider patterns, watermarks — directly in your stylesheet without adding extra <img> tags to the HTML.

For icons used in :before or :after pseudo-elements, the pattern looks like:

.icon-check::before {
  content: url('data:image/svg+xml;base64,PHN2ZyB4bWxucz...');
  display: inline-block;
  width: 16px;
  height: 16px;
}

SVG files can also be embedded unencoded using data:image/svg+xml,[url-encoded SVG]. This keeps the SVG markup readable and saves the 33% Base64 size overhead, which matters if you embed the same icon in many places. For binary formats like PNG and JPEG, Base64 is the only option.

How to Embed Base64 in HTML

The HTML tab outputs a complete <img> element with the src attribute pre-populated. You can paste it directly into any HTML file:

<img src="data:image/jpeg;base64,/9j/4AAQSkZJRg..." alt="Description" />

Update the alt attribute to describe the image for screen readers and for users who cannot display images. All other HTML attributes — width, height, class, loading — work normally with Base64 src values.

In HTML email, keep in mind that some clients impose a maximum message size. If your template with embedded images exceeds around 100 KB of total HTML, certain clients (notably Gmail) may clip the message and show a "view entire message" link, cutting off images at the bottom. For very image-heavy emails, consider hosting the large images and reserving Base64 only for critical elements like logos.

Using Base64 Images in React and Next.js

In React and Next.js, you can assign a Base64 data URL to an <img> or Next.js <Image> component's src prop:

const logo = 'data:image/svg+xml;base64,PHN2Zy...'

export default function Header() {
  return <img src={logo} alt="Logo" width={120} height={40} />
}

Storing the Base64 string as a JavaScript constant in a separate module (for example, assets/icons.ts) and importing it where needed is a clean pattern that keeps component files readable while still bundling the asset. Webpack and the Next.js bundler include the string in the client bundle at build time, so no network request is ever made for the image.

Next.js's built-in <Image> component requires a loader configuration or uses its own CDN for remote images, but it accepts Base64 data URLs directly as the src prop — no special configuration needed. Note that the built-in optimization (resizing, format conversion) does not apply to embedded Base64 images since there is no URL for the optimizer to fetch.

Next.js also accepts a blurDataURL prop for the <Image> component — a low-quality placeholder shown before the full image loads. This prop expects a Base64 data URL, making this tool useful for generating those blur placeholders quickly.

Base64 Image Size Overhead: What to Expect

Base64 encoding increases the size of the data by exactly 33.3% — four output characters for every three input bytes, plus padding characters. A 10 KB PNG becomes approximately 13.3 KB as a Base64 string. This tool calculates and displays the overhead percentage automatically so you do not have to do the math.

The overhead shrinks when the CSS or HTML file is gzip compressed, which HTTP servers apply automatically. Gzip works especially well on repetitive strings, so Base64 text compresses meaningfully. In practice, the effective overhead after gzip is often 10–15% for photographic images and even smaller for simple graphics with repeating patterns.

As a practical threshold: if the Base64 encoded string is under 5 KB, inlining it is almost always worth it. Between 5–20 KB, weigh it against your request budget and caching strategy. Above 20 KB, serve the image as a separate file with proper Cache-Control headers — the caching advantage of a separately hosted file far outweighs the one-request savings.

When NOT to Use Base64 Images

Despite its convenience, Base64 encoding is the wrong choice in several situations:

Large hero images and photographs: A 500 KB hero photo becomes 667 KB as Base64 — embedded in your HTML or CSS file. Every visitor downloads the full string on every page load, even if the image has not changed, because it cannot be cached independently. Serve large images as separate files with long-lived Cache-Control headers so returning visitors load them from disk.

Images used on multiple pages: If the same logo or icon appears on 50 pages of your site, inlining it duplicates the Base64 string 50 times across your HTML or CSS files. A separately hosted file is downloaded once and cached; a Base64 string is repeated in every file that uses it.

Images the user uploads: When users upload images that then appear on the page (profile photos, document previews), use URL.createObjectURL(file) instead of Base64. Object URLs are references to the in-memory file and do not copy the entire file into a string, which avoids creating a massive string in memory and the DOM for large uploads.

Images that change frequently: If an image is updated often — a live dashboard chart, a regularly refreshed photo — Base64 forces the entire surrounding HTML or CSS file to be re-downloaded every time the image changes, defeating any caching benefit. A separate image URL with a short cache TTL or cache-busting query parameter is the right pattern.

Frequently Asked Questions