Image to Base64 Converter - Encode Images as Data URIs

Because Base64 is an encoding, not a compressor. It represents 3 bytes of binary using 4 printable ASCII characters, so the output is always about 33% longer than the input, plus a few bytes for the data: prefix. That growth is inherent to the format and there is no setting that avoids it. If you need a smaller file, compress the image before encoding it — the encoding step can only add.

Inline when the asset is small and always needed: icons, 1x1 spacers, tiny background textures, roughly under 10 KB. Below that, saving an HTTP request usually beats the 33% size penalty. Do not inline photos, hero images, or anything above about 100 KB. A large data URI cannot be cached independently, has to be re-downloaded with every page or stylesheet revision, and blocks the parser until it has been read through.

Often not. Gmail strips data URIs from img tags outright, and Outlook's desktop clients have never supported them reliably. Apple Mail and some webmail clients do render them. The dependable approach for email is still a hosted image URL, or a CID attachment referenced with cid: in the src. Test in the clients your recipients actually use before relying on inline data.

Yes, and it is lossless — the decoded bytes are identical to the original file, including EXIF and color profile data. Paste a full data URI into a browser address bar and the image renders. In code, atob() in JavaScript or base64 -d on the command line will do it. Note that the raw output on this page omits the data: prefix, so add it back if the target expects a full URI.

No. SVG is already text, so Base64 adds 33% for nothing. Paste the markup straight into your HTML instead, which also lets CSS style the shapes and JavaScript reach them. For CSS backgrounds, use a URL-encoded SVG in url() rather than a Base64 one — it stays smaller and gzips better. Base64 for SVG only makes sense where a strict URI is required and percent-encoding is not an option.

There is no limit in the HTML or CSS specification, and modern browsers handle multi-megabyte data URIs in src attributes. The practical ceilings are elsewhere: URL bars typically cut off around 2 MB or less, some server and CDN configurations cap header and request sizes, and very long strings slow down parsing noticeably. This tool imposes no cap of its own, but it warns above 100 KB because that is where inlining stops being worthwhile.

No. The file is read with the browser's FileReader API, which operates on the local file handle, and the resulting string stays in the page's memory. Nothing is sent over the network and there is no server-side component, so the tool keeps working offline once the page has loaded. Clipboard copies go through the standard browser clipboard, not through us.

All of them for images — data URIs in img src and CSS url() have worked since IE8 and are universally supported today. The clipboard is the newer piece: navigator.clipboard requires a secure context, so on plain HTTP or in older browsers this page falls back to selecting the textarea and using document.execCommand('copy'). If both paths fail you will see a message asking you to select and copy the text yourself.