Image to Base64

The Image to Base64 converter turns an image file into a Base64-encoded data URI you can paste directly into HTML, CSS, JSON, or source code. It accepts PNG, JPEG, GIF, WebP, SVG, and BMP, reports exactly how much the encoding inflates the file, and runs completely in the browser — the image is never uploaded.

How to Use

1. Drag an image onto the upload zone or click to choose a PNG, JPEG, GIF, WebP, SVG, or BMP file.
2. The preview appears immediately, and the tool reads the file with the FileReader API.
3. Review the four statistics: MIME type, original size, Base64 size, and the percentage increase.
4. Copy the full data URI with one click, prefix included.
5. Paste it wherever a URL would normally go — an img src, a CSS background-image, or a JSON field.

Placement matters. In HTML the string goes straight into the attribute: <img src="data:image/png;base64,iVBORw0KGgo...">. In CSS it sits inside a quoted url(): background-image: url("data:image/svg+xml;base64,PHN2Zy...");. In JSON it is simply a string value. Keep the semicolon between the MIME type and base64; removing it invalidates the URI and the image fails silently. In CSS, always quote the value, because an unquoted data URI can break on a ) inside an SVG payload.

The Arithmetic Behind the 33% Overhead

Base64 uses a 64-character alphabet so the result is safe to paste into text-only channels. Every 3 input bytes map to 4 output characters, which gives the fixed ratio:

encoded length = ceil(bytes / 3) × 4

The tool reverses that to estimate the original size: it takes the Base64 payload length, multiplies by 3/4, and subtracts 1 or 2 characters for any trailing = padding. That is why the reported “original size” matches the file almost exactly. The visible overhead is therefore 33.3% plus the short prefix — for example data:image/png;base64, is 22 extra characters.

Padding appears whenever the byte count is not divisible by three. One leftover byte produces two characters plus ==; two leftover bytes produce three characters plus =. A payload whose length is a multiple of three ends with no padding at all. Without the correction the encoded string would appear slightly larger than it really is, so the subtraction keeps the estimate honest.

Worked Examples

Source file	Base64 payload	Increase shown	Approx. data URI
1 KB icon	~1.37 KB	~33.3%	~1.39 KB with prefix
10 KB logo	~13.7 KB	~33.3%	~13.7 KB with prefix
100 KB photo	~133 KB	~33.3%	~133 KB with prefix

The ratio is constant; only the absolute bytes change. A 4 KB PNG and a 4 MB PNG both grow by a third.

When an Inline Data URI Wins

• Icons, favicons, and small logos that would otherwise cost an extra HTTP request on every page.
• Single-file HTML documents and offline demos that must not depend on external assets.
• JSON payloads that need to carry a thumbnail without a multipart upload.
• Email templates where the client is known to render data URIs.
• CSS background-image rules for tiny decorative textures.

When It Loses

Each data URI is embedded in the document, so it cannot be cached separately. If the same icon appears on twenty pages, the browser downloads those bytes twenty times instead of once. The encoding also inflates every asset by a third, and a very large data URI inside a stylesheet blocks rendering while it parses. For images above about 10 KB, an external file with proper cache headers is almost always the better trade.

The arithmetic makes the point. A 6 KB icon inlined in a shared stylesheet is fetched once, but the same icon pasted into each page’s HTML is fetched twenty times — 120 KB transferred where an external file would transfer 6 KB on first load and nothing after. Repeat that across a small icon set and the total grows quickly. The rule of thumb: inline only when the image is tiny and a separate request would cost more than the overhead.

Accuracy and Limits

• Size figures come from the decoded Base64 length, not from a fresh byte count of the file, so they can differ by a byte or two on unusually padded files.
• The tool encodes; it does not compress. A PNG stays a PNG and a JPEG stays a JPEG.
• Inline images are not automatically optimised, so it is worth running a large photo through a compressor before encoding it.
• The prefix must use the correct MIME type. A PNG labelled image/jpeg may still render because browsers sniff the bytes, but strict tooling can reject it.
• Very long strings are awkward to store and review. Editors slow down, and some build pipelines truncate values beyond a few hundred kilobytes.
• Clipboard copying uses the modern Clipboard API with a fallback for older browsers; on some browsers the fallback requires a user gesture.

Related Tools

• Base64 Encoder/Decoder — encode and decode arbitrary text, not just images.
• Image Compressor — shrink the image before inlining it.
• Image Format Converter — switch formats before encoding.