A data URL turns a file into text that lives inside your code
A normal image reference — an `<img src="logo.png">` — points to a separate file the browser has to request over the network. A data URL replaces that pointer with the image's actual bytes, re-encoded as base64 text and embedded directly in the string: `data:image/png;base64,iVBORw0KG...`. There's no separate file, no separate HTTP request — the browser decodes the base64 text right where it sits and renders it.
This is a genuine trade-off, not a strict improvement. Base64 encoding itself inflates the data by roughly 33% compared to the raw binary file, since it's representing 8-bit binary data using a 64-character text alphabet. You're trading a network request for a larger payload embedded directly in your HTML, CSS, or JSON.
When inlining helps vs. when it hurts
| Scenario | Inlining helps | Why |
|---|---|---|
| Small icons used once (favicons, UI glyphs) | Yes | Saves a full HTTP round-trip for a tiny file |
| Self-contained HTML demos or reports | Yes | No external files needed to share or archive |
| Email HTML images | Yes | Many email clients block or strip external image requests |
| Large photos or hero images | No | The ~33% size inflation and lack of separate caching outweigh saved requests |
| Images reused across many pages | No | A separate file gets cached once by the browser; inlined copies repeat in every page's payload |
Creating a data URL
Drop an image onto the zone — PNG, JPG, WebP, GIF, or SVG.
Optionally change the output format and quality.
Copy the data URL to your clipboard, or save it as a self-contained HTML file.
Paste it directly into an HTML `<img>` src, a CSS background property, or a JSON field.
Why SVG behaves differently from every other format here
Raster formats (PNG, JPG, WebP, GIF) get base64-encoded as-is — pixels in, base64 text out, no change to image quality. SVG is different: it's already a text-based vector format, not pixels, so encoding it doesn't rasterize or degrade it in any way. The resulting data URL still describes shapes and paths mathematically, meaning the embedded SVG stays infinitely scalable — zoom in as far as you like and it stays crisp, unlike a base64-embedded raster image which is still just a fixed grid of pixels underneath.
Judging when the size trade-off is worth it
There's no tool-imposed size limit, but practical limits come from where you're pasting the result: browsers and CSS parsers can technically handle data URLs into the megabytes, but very long strings make source files harder to read, harder to diff in version control, and slower to parse. As a rough guide, small UI icons and logos (a few KB) are comfortable candidates; a multi-megabyte photo becomes a genuinely large embedded string that's usually better served as a separate file with normal browser caching.
Common mistakes
Inlining a large photo that's reused on many pages — each page's HTML now carries the full inflated copy, instead of the browser caching one shared file.
Assuming base64 encoding shrinks a file — it does the opposite, inflating size by roughly a third versus the raw binary.
Base64-encoding a raster icon when an SVG source was available — you lose the scalability an SVG data URL would have kept.
Pasting a very long data URL into a context with strict length limits (some CSS tooling, older email clients) without checking it fits.
Real use cases
Embedding a small logo directly in an HTML email so it displays even when a client blocks external images.
Building a single self-contained HTML file — a demo, an offline report, a shareable prototype — with no external image dependencies.
Inlining a tiny UI icon into CSS as a `background-image` to avoid a separate network request.
Embedding an image reference directly inside a JSON payload for an API or config file that needs to be self-contained.
Frequently asked questions
Q: What is a data URL?
A: A data URL embeds the file's contents directly in the URL string, like `data:image/png;base64,...`, letting you inline images without a separate HTTP request.
Q: How large can the data URL be?
A: There's no limit set by this tool, but very large images produce very long strings, and CSS and HTML have practical limits around a few megabytes before things get unwieldy.
Q: Why use base64 instead of a file?
A: It reduces HTTP requests and is useful for emails, single-file demos, or embedding small icons. For large images, a separate file is usually the better choice.
Q: Does it work with SVG?
A: Yes — SVG is encoded directly as base64 without re-rasterizing, so it stays infinitely scalable in the resulting data URL.
Q: Are my images uploaded?
A: No. Encoding happens entirely in your browser.
Q: Will a base64-embedded image be cached the same way a linked file is?
A: No — a data URL is part of the page's own HTML, CSS, or JSON payload, so it gets re-downloaded every time that containing file is fetched, unlike a separate image file the browser can cache independently across page loads.
Convert your image now
Generate a data URL with Image to Base64. Need a different output format first? Try the Image Converter. Working with a large image? Shrink it first with the Image Compressor, or generate a properly sized icon with the Favicon Generator.
