What Is Base64 Data URI? A Simple Expert Guide With Real Examples

What Is Base64 Data URI? Real Examples

by

You have probably seen an <img> tag whose src is not a URL but a wall of gibberish starting with data:image/png;base64,iVBORw0KGgo.... If you have ever wondered what is Base64 data URI and why anyone would embed an image directly in HTML instead of linking to a file, this guide is for you. The short answer: a data URI lets you put the file’s contents where a URL would normally go — and Base64 is the encoding that makes binary contents safe to paste as text.

Below: the syntax broken into plain English, three real working examples (image tag, CSS background, favicon), and — the part most tutorials skip — the honest tradeoffs. Data URIs are not free: they cost you ~33% in size, they defeat browser caching, and the old “fewer HTTP requests” argument is weaker than it used to be. Our free Image to Base64 converter generates them for you when the tradeoffs make sense.

Table of Contents

What Is Base64 Data URI: The Syntax, Broken Down

Every data URI follows the same shape, defined by RFC 2397:

data:[<mediatype>][;base64],<data>

Reading a real one left to right — data:image/png;base64,iVBORw0KGgoAAAANSUhEUg...:

  • data: — the scheme. It tells the browser “what follows is not a location, it is the content itself.”
  • image/png — the MIME type, declaring what kind of data this is. Could be image/svg+xml, font/woff2, text/css, anything.
  • ;base64 — the encoding flag. It says the data after the comma is Base64-encoded binary. Without it, the data is treated as URL-encoded text.
  • , — the separator between metadata and payload.
  • iVBORw0KGgo... — the actual file contents, encoded as Base64 text.

So when someone asks what is Base64 data URI at the mechanical level, the answer is: a way to inline a file’s bytes directly into HTML or CSS, with Base64 translating the raw bytes into plain ASCII text that will not break the surrounding markup.

What the Base64 Part Actually Does

Binary files — PNGs, fonts, PDFs — contain byte values that are not valid text: null bytes, control characters, bytes that would terminate a string or corrupt HTML parsing. You cannot paste raw binary into an HTML attribute. Base64 solves this by re-encoding every 3 bytes of binary into 4 ASCII characters drawn from a safe 64-character alphabet (A–Z, a–z, 0–9, +, /).

The arithmetic is exact and worth knowing: 3 bytes become 4 characters, so Base64 output is always 4/3 the size of the input — a 33.3% overhead, plus up to 2 padding characters (=) at the end. A 3,000-byte icon becomes ~4,000 characters of text. A 300 KB photo becomes ~400 KB of text. This is not compression or encryption — it is a straightforward, reversible translation, and every browser decodes it natively with zero libraries.

One clarifying note for a common confusion: Base64 and data URIs are independent ideas. Base64 is just an encoding (used in email attachments, JWT tokens, and APIs everywhere). A data URI is just an inlining scheme (which can carry URL-encoded text without Base64 at all). They are combined constantly, which is why people conflate them — but understanding them separately makes both clearer. This separation is the key insight whenever someone asks what is Base64 data URI and gets a muddled answer: two independent ideas, one common combination.

Three Real Base64 Data URI Examples

1. Image tag

The classic use — an icon embedded directly in HTML, no separate file request:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mP8z8BQDwAEhQGAhKmMIQAAAABJRU5ErkJggg==" alt="Red dot">

(That decodes to a 1×1 red pixel — the standard minimal example of what is Base64 data URI in practice. Real icons are longer but structurally identical.)

2. CSS background

Small repeating textures or icons in stylesheets, keeping everything in one file:

.icon {
  background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjwvc3ZnPg==");
}

SVG is the sweet spot here: vector icons are tiny, and inlining them avoids a request per icon. Note that SVG data URIs are often URL-encoded rather than Base64 — Base64 is required only for true binary; text-based formats have the choice.

3. Favicon

A complete favicon with zero extra files:

<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'><text y='14'>⚙</text></svg>">

This one skips Base64 entirely (URL-encoded SVG text) — a good reminder that “data URI” does not always mean “Base64.” Browsers have supported SVG favicons via data URI for years, making this the simplest possible favicon setup.

When to Use a Data URI (and When Not To)

Once you understand what is Base64 data URI and what it costs, the decision rules are simple. Use a data URI when: the asset is tiny (icons, 1×1 spacers, small logos under ~2–4 KB), it is critical to first paint (above-the-fold icons that should not wait for a round trip), you are generating a single self-contained file (an HTML email, an exported report, a demo page), or you are embedding a font subset in CSS.

Do not use a data URI when: the asset is large (photos, big illustrations — the 33% tax hurts and the HTML becomes unmanageable), the asset is reused across pages (see caching below), the asset changes often (every change invalidates the entire containing HTML/CSS file’s cache), or you are inlining into HTML that is already large. A 200 KB image as a data URI inside your HTML means every visitor downloads those ~266 KB of Base64 with every page view, even on pages that never show the image — if it sits in a shared template.

The Honest Costs: 33% Bigger, Uncacheable

Two costs that tutorials routinely underplay when explaining what is Base64 data URI:

Cost 1: the size tax is real and exact. Base64 inflates binary by exactly one-third. A 90 KB hero image becomes 120 KB of text inside your HTML. On metered mobile connections, that is not nothing — and unlike image compression, it buys you zero visual improvement. For anything photographic, the tax alone usually disqualifies data URIs.

Cost 2: no separate caching. A linked image file gets its own cache entry with its own lifetime — change your HTML, the image stays cached. An inlined data URI is part of the HTML or CSS: it re-downloads with every fresh fetch of that file, and updating the image means invalidating the whole document’s cache. For shared assets (logos on every page), this is pure waste multiplied by every pageview.

Cost 3 (the outdated argument): HTTP requests. Old tutorials claim data URIs “save an HTTP request” as if requests were precious. With HTTP/2 and HTTP/3 multiplexing, the per-request overhead is far smaller than it was in the HTTP/1.1 era those tutorials were written for. Eliminating a request for a 2 KB icon still helps marginally; restructuring your image strategy around it does not. Measure, do not memorize.

Data URI vs URL: The Decision Table

  • Tiny icon, used once, critical to render: data URI wins.
  • Logo reused on every page: URL wins (cached once, reused everywhere).
  • Photo or large illustration: URL wins, always — the 33% tax is unjustifiable.
  • Single-file deliverable (email, export): data URI wins — self-containment is the whole point.
  • Frequently updated asset: URL wins — update the file, keep the cache.

Notice the pattern: data URIs win on self-containment, URLs win on efficiency at scale. Most production sites end up with a hybrid — a handful of inlined critical icons, everything else as files. That hybrid is what is Base64 data URI used wisely: a deliberate tool for self-containment, not a default.

Try It: Image to Base64 Converter

Once you have decided what is Base64 data URI is right for your use case, generating one by hand is error-prone — a single wrong character corrupts the image. Our free Image to Base64 converter encodes your image and produces the complete data: URI, ready to paste. For non-image Base64 work, the Base64 encoder/decoder handles arbitrary text, and if you are embedding SVG markup rather than binary, our HTML entity encoder keeps the angle brackets safe. The URI scheme itself is specified in Wikipedia’s Data URI scheme article, and MDN’s Data URLs guide covers browser behavior in depth.

Frequently Asked Questions

What is the difference between Base64 and a data URI?

Base64 is an encoding that converts binary bytes into safe ASCII text (with a 33% size overhead). A data URI is a URL scheme (data:…) that embeds file contents directly instead of linking to a location. They are independent concepts that are frequently combined: the data URI carries the file, Base64 makes binary files safe to carry as text. If you can explain what is Base64 data URI, you can explain both halves — the encoding and the scheme.

Does Base64 make images bigger?

Yes — by exactly one-third. Base64 turns every 3 bytes into 4 characters, so a 3,000-byte image becomes about 4,000 characters of text. It is a translation, not compression. Never use Base64 to “optimize” an image; it always makes it larger.

When should I use a data URI instead of an image file?

For tiny assets (icons under a few KB) needed immediately on first paint, or when you need a single self-contained file (HTML emails, exports, demos). For photos, large images, assets reused across pages, or anything updated often, a separate linked file wins on size and caching.

What is the data URI syntax?

data:[mediatype][;base64],data — for example data:image/png;base64,iVBORw0K…. The data: scheme says “this is content, not a location”; the MIME type declares the format; ;base64 flags Base64 encoding; the comma separates metadata from payload.