I have a confession that will make performance engineers wince. On an early version of a WordPress dashboard for WP Adminify, I base64-encoded every icon and inlined them straight into the CSS because I was tired of managing sprite sheets. It worked. The icons appeared instantly, no extra requests, no flash of missing image. Then the stylesheet ballooned past a megabyte and the page felt slower on second load, because none of those inlined images could be cached on their own. That project is where I learned that "image to base64" is a genuinely useful technique that is also easy to overuse.
This guide covers both halves of that lesson. I will show how to convert an image to base64 with the Image to Base64 Converter on toolz.dev, how to decode base64 back into an image, what a data URI really is, and the honest trade-offs so you inline the assets that benefit and leave the ones that do not.
TL;DR: Converting an image to base64 turns its binary contents into a text string, usually wrapped in a data URI like
data:image/png;base64,iVBORw0KG.... That string embeds directly in HTML, CSS, SVG, or JSON with no separate file request. The toolz.dev converter encodes and decodes in both directions, runs entirely in your browser so no image is ever uploaded, and gives you the raw base64, a ready data URI, an<img>tag, and a CSS snippet. Base64 inflates size by about a third, so inline small assets like icons, not large photos.
What is a base64 image, exactly?
Base64 is an encoding scheme, not compression and not encryption. The scheme is defined by RFC 4648, and the data: URI that wraps it by RFC 2397. It represents arbitrary binary data using 64 printable ASCII characters: the letters A to Z and a to z, the digits 0 to 9, plus + and /, with = used for padding. The scheme is defined in RFC 4648, the same standard that governs the base64 you see in email attachments and JSON payloads.
The reason it exists is that a lot of the internet's plumbing was built for text, not raw bytes. Binary data can contain byte values that a text-oriented channel will mangle. Base64 sidesteps that by taking three bytes of input, splitting those 24 bits into four groups of six, and mapping each group to one of the 64 characters. Three bytes in, four characters out. That three-to-four ratio is exactly why encoded output is roughly 33 percent larger than the source, a number worth memorizing because it decides whether inlining is a good idea.
A "base64 image" is simply an image file that has been run through that encoding. On its own the string is just text. What makes it renderable is wrapping it in a data URI.
What is a data URI and why does the browser render it?
A data URI is a URL that carries its payload inline instead of pointing to a remote resource. Its shape, defined in RFC 2397, is data:[<media-type>][;base64],<data>. For a PNG that looks like data:image/png;base64,iVBORw0KGgo....
The important piece is the media type, image/png in that example. It tells the browser how to interpret the bytes that follow. Because the data URI announces its own MIME type, a browser can treat data:image/png;base64,... as a picture the instant it parses an attribute that expects a URL, whether that is the src of an <img> or the url() in a CSS background-image. No network round trip happens, because there is nothing to fetch. The image is already there, spelled out in the markup.
That is the whole magic and the whole cost in one sentence. The image is already there, which is why it renders instantly, and also why it cannot be cached separately or shared between pages the way a linked file can.
How do I convert an image to base64 on toolz.dev?
The Image to Base64 Converter has two directions, and encoding is the default.
Pick the "Image to Base64" direction, then upload or drop your image. The tool reads the file locally using the browser File API, and because that read happens in your browser, the image never travels to a server. Once it is loaded you get a preview plus four outputs, each with its own copy button.
The raw base64 is the bare string, useful when you already have your own wrapper. The data URI is the full data:... string ready to paste into an src or url(). The HTML <img> tag is a complete element you can drop into a template. The CSS background-image declaration is ready for a stylesheet. Alongside those you see the decoded byte size and the base64 character count, so you can judge the weight before committing. If the number looks alarming, that is the tool doing its job: a 200 KB photo becoming a 270 KB string in your HTML is exactly the moment to reconsider.
How do I decode base64 back into an image?
Switch to the "Base64 to Image" direction and paste either a raw base64 string or a complete data URI. The converter is tolerant about input: it strips whitespace, and if you paste a full data:image/png;base64,... string it reads the MIME type straight out of the prefix. If you paste bare base64 with no prefix it assumes PNG, which is the safe default for most screenshots and exported assets.
It validates the string first. If what you pasted is not plausible base64, meaning it contains characters outside the RFC 4648 alphabet, the tool tells you rather than showing a broken image. When the input checks out, you get a live preview and a download button that rebuilds the original binary file and saves it with the right extension. This direction is genuinely handy when you find a data URI buried in a stylesheet or an API response and want to see what it actually is, or extract it back to a real file.
Everything here is client-side, which is the same promise that runs through the rest of the toolbox, from the text-oriented Base64 Converter to the URL Encoder. If you want the broader reasoning behind keeping this kind of work in the browser, the base64 encoding guide goes deeper on the encoding itself.
When should I inline an image as base64, and when should I not?
This is the decision the tool exists to inform, so here is the table I actually use.
| Situation | Inline as base64? | Why |
|---|---|---|
| Small icon or logo used site-wide | Often yes | Removes a request, appears instantly, overhead is tiny |
| Tiny SVG or 1px background | Yes | The 33 percent overhead is negligible on a few hundred bytes |
| Single-file HTML export or email | Yes | The file must be self-contained, no external assets allowed |
| Large hero photo or banner | No | Overhead is large and the image cannot be cached separately |
| Image reused across many pages | No | A linked file caches once and is shared; inlining duplicates it everywhere |
| Content image that changes often | No | Editors cannot swap a base64 blob as easily as a file |
The pattern behind the table is simple. Inlining trades a network request for bytes in your document. That trade wins when the asset is small and the saved request matters, which is the classic case for icons above the fold. It loses when the asset is large or shared, because you pay the 33 percent tax, you lose independent caching, and you bloat the very file the browser must parse before it can paint anything.
For the "no" rows, the better move is usually to optimize the file and serve it normally. That is where a tool like Image Compress or the Format Converter earns its keep, shrinking the asset so the linked version is as light as possible. I wrote more about that whole workflow in the web developer toolkit guide.
Does base64 keep my image private?
Yes and no, and the distinction matters. Base64 is an encoding, so anyone who has the string can decode it back to the exact original image. It provides zero secrecy. Do not treat a data URI as a way to hide anything, because the "Base64 to Image" direction of this very tool reverses it in one paste.
What is private is the conversion itself. On toolz.dev the image is read and encoded entirely in your browser with the File API, and nothing is uploaded. So the artwork, the screenshot, the client logo you are encoding never leaves your machine during the process. That is a different guarantee from the encoding hiding the content, and I try to be precise about it because "private" gets thrown around loosely. The privacy is in the local processing, covered more broadly in the data privacy guide, not in base64 as a scheme.
A few practical tips from shipping this
Prefer SVG for icons when you can, and inline the SVG markup directly rather than base64-encoding it. SVG is already text, so wrapping it in base64 only adds the 33 percent tax for nothing. Base64 shines for raster formats like PNG and JPEG that are genuinely binary.
Watch the total document size, not just the single image. One inlined icon is invisible. Forty of them, the mistake I made on that WordPress dashboard, turn a lean stylesheet into a monster. If you are inlining more than a handful, that is a signal to step back and consider a linked sprite or an icon font instead.
Keep the MIME type honest. If you export a JPEG but label its data URI as image/png, some browsers cope and some do not. The converter detects the real type from the file so the output is correct, but if you hand-assemble a data URI elsewhere, match the media type to the actual bytes.
And when you inherit a codebase full of mystery data URIs, remember the decode direction. Pasting one into the "Base64 to Image" side and hitting download is the fastest way to see what a stylesheet is actually shipping.
How does base64 encoding actually work, step by step?
It helps to see the mechanics once, because the whole 33 percent overhead story falls out of it naturally. Base64 works on groups of three bytes at a time. Three bytes is 24 bits. The encoder slices those 24 bits into four chunks of six bits each. Six bits can represent 64 values, from 0 to 63, and each of those values maps to one character in the base64 alphabet: A through Z for 0 to 25, a through z for 26 to 51, the digits 0 to 9 for 52 to 61, then + for 62 and / for 63.
So three input bytes always become four output characters. That is the source of the size increase. Four characters carry the information of three bytes, a ratio of 4 to 3, which is the same as saying the output is one third larger than the input. There is no way around it, because it is baked into how the scheme works.
Padding handles the leftovers. If your data is not a clean multiple of three bytes, the encoder pads the final group so it still produces a whole number of characters, and it appends one or two = signs to record how much padding it added. That is why base64 strings so often end in = or ==. A single trailing = means the last group held two bytes; a double == means it held one. The toolz.dev converter handles padding automatically in both directions, and when decoding it happily accepts strings with or without the trailing =, because some systems strip it.
You can watch this play out with a tiny example. The three ASCII bytes for the letters "Man" encode to the four characters "TWFu", a famous example straight out of the encoding literature. Drop those same three characters into a data URI as text and you can see the round trip, or run a real image through the tool and notice that the character count in the output is always about four thirds of the byte count shown next to it.
Understanding this also explains why base64 is a poor fit for large images and a fine fit for tiny ones. The overhead is a fixed percentage, so on a 300 byte icon it costs you 100 bytes, nobody cares. On a two megabyte photo it costs you two thirds of a megabyte of pure text bloat in your document, and that document has to be downloaded and parsed before the page can render. The math does not change with size, but the consequences do.
Frequently asked questions
How do I convert an image to Base64?
Choose the Image to Base64 direction, then upload or drop your image. The tool reads the file locally, encodes it, and returns the raw Base64 plus a ready-to-use data URI, an img tag, and a CSS snippet you can copy.
What is a data URI?
A data URI is a string that embeds a file inline instead of linking to it, in the form data:[mime-type];base64,[data]. For a PNG it looks like data:image/png;base64,iVBORw0KGgo... Browsers render it as an image wherever a URL is expected, so no separate request is needed.
Can I convert Base64 back to an image?
Yes. Switch to the Base64 to Image direction and paste either a raw Base64 string or a complete data URI. The tool decodes it, shows a preview, and lets you download the reconstructed image file.
Which image formats are supported?
PNG, JPG/JPEG, GIF, WebP, SVG, BMP, ICO, and AVIF are all supported. The correct MIME type is detected from the file so the resulting data URI renders correctly.
Why is the Base64 string larger than my image?
Base64 represents three bytes of binary data with four text characters, so encoded output is about 33 percent larger than the source. That overhead is why Base64 suits small icons and logos more than large photographs.
Is it safe to convert images here?
Yes. Every image is read and encoded entirely in your browser using the File API. No file, string, or result is uploaded to a server, so private images stay on your device.
Should I inline images as Base64 in production?
Inlining works well for small, frequently used assets such as icons because it removes an HTTP request and avoids a flash of missing image. For large images it is usually better to keep separate files so the browser can cache them independently.
Does the converter work offline and on mobile?
Yes. Because all processing is client-side, it works after the page has loaded even without a connection, and the interface is responsive across modern desktop and mobile browsers.
