Image to Base64 encoder

This tool reads an image and returns it as a Base64 data URL — a single long text string that begins with data:image/…;base64, followed by the encoded bytes of the file. Because the result is plain text, you can paste it directly into HTML, CSS, JSON, Markdown, or an email template and the image travels inline with the code instead of as a separate file. You can copy the string to your clipboard or download it as a .base64.txt file.

The output includes the full data: prefix, which is what makes it usable as a drop-in source. In HTML that means <img src="data:image/png;base64,…">; in CSS, background-image: url("data:image/png;base64,…"). If a destination wants only the raw encoded payload without the prefix, delete everything up to and including the comma.

Reach for this when a tiny asset is easier to inline than to host — a small icon, a 1-pixel spacer, an SVG sprite, a logo in an HTML email, or test data for a code sample. It is a developer convenience, not an image editor: the pixels are unchanged, only the container format is.

Base64 rewrites binary bytes using a 64-character alphabet so the data survives places that only accept text. It is reversible by anyone — it does not hide, protect, or encrypt the image in any way. Never treat a Base64 string as a secret; if the underlying image is sensitive, the encoded text is exactly as exposed as the file.

Encoding also does not make the file smaller. Base64 inflates the data by roughly a third, because every three bytes become four text characters. A 30 KB PNG becomes about 40 KB of text. If your goal is a smaller file, that is a job for the Compress Image tool, not this one — Base64 will always grow it.

Two practical consequences follow from that overhead. First, inlining is best for genuinely small assets; pasting a large photo produces an enormous, unwieldy string. Second, the encoded text is bigger than the original, so it costs slightly more bandwidth per request unless caching offsets it — which is the trade-off covered next.

Inlining removes a separate network request, which can speed up the first paint for a handful of tiny, above-the-fold assets — an icon or a small background that the page needs immediately. It is also handy when a file cannot easily reference external images: a self-contained HTML email, a single-file export, a Markdown document, or a JSON payload that must carry its own artwork.

The cost is caching. A normal image file is downloaded once and reused across every page from the browser cache. An inlined Base64 image is part of the HTML or CSS, so it is re-sent with every page that contains it and cannot be cached on its own. For anything used on more than one page, or for anything larger than a few kilobytes, a regular hosted file almost always wins. A good rule of thumb: inline only small, single-use, rarely-changing assets.

Keep maintainability in mind too. A long data URL is hard to read in source control and awkward to update. If an inlined image needs to change often, host it as a file so you can swap it without editing the markup.

Encoding happens entirely in your browser using the built-in file reader. On this site, your image is processed on your own device and is not uploaded to our servers, and nothing is stored once you close or reload the page — so it is fine to encode an asset you have not published. To decode a Base64 string back into a viewable, downloadable image, use the Base64 to Image tool.

If the result looks wrong when you paste it, the most common cause is a truncated copy or a missing prefix at the destination. Copy the full string again, and make sure the consumer either keeps the data: prefix (for an <img> or CSS url) or strips it (for a raw byte field) — but not a mix of the two.