What you get back is a data URL
Not raw base64 — a complete data URL, beginning with data:, naming the file's type, and carrying the encoded image after it.
That prefix is part of what makes the output usable. Pasted into a stylesheet or an <img> tag it works as it stands, because the browser is told what it is looking at before the data begins. Strip it only if something is specifically asking for the base64 alone.
The [msm_tool slug="image-to-base64"] reads the file in your browser, so nothing is uploaded.
The size cost is about a third
Base64 turns every three bytes into four characters, so expect the encoded version to be roughly 33% larger than the file it came from. That is the trade being made, and whether it is worth it depends entirely on the size of the image.
In exchange, the image needs no separate request. It travels inside the HTML, CSS or JSON that references it, and it cannot arrive late, arrive out of order, or go missing.
Where embedding wins
- Small, unchanging assets. An icon, a bullet, a one-pixel gradient, a spinner. Below a few kilobytes the saved request usually outweighs the extra bytes.
- Assets that must not fail. A logo in an error page that renders when the rest of the site is down.
- Single-file deliverables. An HTML email, a self-contained report, a document someone will save and open offline.
Where it loses, and badly
Large images. A photograph inlined into a stylesheet makes that stylesheet render-blocking — the page cannot paint until the whole thing arrives, including an image the browser would otherwise have loaded in parallel. A 200KB photograph becomes 270KB of CSS that everything waits for.
Anything cacheable. An embedded image cannot be cached on its own. It is re-downloaded with its host file every time that file changes, where a separate image would have stayed in the browser cache across deployments. Inline a logo into your main stylesheet and every CSS change re-sends the logo to everyone.
Anything reused. The same icon embedded in five places is five copies. Referenced as a file, it is one request and then cache.
Email is the awkward case
Inlined images cannot be blocked as remote content, which is genuinely useful — most clients block remote images by default and your carefully designed email arrives as boxes.
But several major clients, Gmail among them historically, refuse data URLs in HTML email outright. So the technique solves one problem and can create another. Test in the clients your audience actually uses before committing to it; for email, a hosted image with good alt text is often still the safer choice.
SVG is usually better inlined as itself
If the image is an SVG, embedding the markup directly is almost always better than base64-encoding it. It is smaller than the encoded version, it can be styled with CSS, and it compresses well because it is text.
Base64 an SVG only when it must sit in a CSS url() and you cannot use the markup directly — and even then, URL-encoding the SVG rather than base64-encoding it produces a smaller result.
A rough rule
Under about 4KB, embedding is usually worth it. Between 4KB and 10KB, it depends on how often the host file changes. Over 10KB, use a file.
Those numbers are not precise and they do not need to be — the cases at either end are obvious, and the middle rarely matters much either way.