Make your Base64 images smaller

Paste it above: raw Base64, a full data URI, or a value copied from CSS or JSON all work, and the tool inspects the decoded bytes to identify the format.

In a page, the complete data URI is the image address: <img src="data:image/png;base64,..." alt="Logo">, or background-image: url("data:image/png;base64,...") in CSS. Raw Base64 without the data:image/png;base64, prefix isn't a valid source on its own. Command-line tools want the opposite, the raw payload without the prefix: base64 -d image.txt > image.png (older macOS versions use -D), or Buffer.from(payload, "base64") in Node.js.

Base64 is an encoding, not compression: it writes every 3 bytes as 4 characters, so n bytes become 4 × ceil(n / 3) characters. A 3,000-byte PNG turns into 4,000 characters, plus the 22-character data:image/png;base64, prefix, for 4,022 in total.

For real images the overhead settles at 33⅓%; for tiny ones, padding and the prefix make it proportionally larger. In email, MIME also splits Base64 into lines of at most 76 characters, which adds line breaks on top.

They can win back much of it. Base64 carries only 6 bits of information in each 8-bit character, and general-purpose compressors exploit that slack; how much they recover depends on the image data, the compressor and its settings. Compare compressed responses, not character counts.

Some costs remain either way: the image can't be cached apart from the HTML or CSS that carries it, and the browser has to decompress and decode the text. Where nothing compresses the transfer, as in many email pipelines, you pay the full overhead. The lengths shown here are data URI lengths, not network sizes.

Inline what is small, stable and needed immediately: an icon, a placeholder, images in a self-contained HTML file or a JSON payload. Use separate files for anything large, shared between pages or updated often. An inlined image can't be cached as its own resource, and its bytes travel with the containing document even when the image is lazy-loaded; every change to that file sends it again.

There is no universal size cutoff. HTTP/2 and HTTP/3 made small extra requests cheaper, so inlining to save a request matters less than it used to, but latency and cache reuse still count. Measure for your pages.

Start with the pixels: halving both dimensions cuts the pixel count to about a quarter, at the cost of detail. Then choose the format: WebP for photos and illustrations, a lossless or reduced-palette PNG for logos, screenshots and pixel art, cleaned-up markup for SVG.

Auto mode does the comparison for you. It encodes each eligible format (lossless PNG up to 4 million pixels, JPEG only for opaque images) and keeps the shortest data URI, prefix and padding included. The built-in 240 × 160 example drops from 4,190 to 2,006 characters with an optimized PNG; that's one test image, not a promise.

Usually because the source was already efficient. Tiny images are dominated by file headers, well-optimized PNGs leave little to gain, and switching formats can go the wrong way: a photo saved as lossless PNG, or a flat logo saved as JPEG. Re-encoding can't recover detail lost in an earlier JPEG conversion, and may add new artifacts.

At unchanged dimensions, Auto keeps the original when no candidate produces a shorter data URI. When you force a format or change the size, the tool shows the increase in red instead of hiding it.

Try WebP first for photos and illustrations; it also supports transparency. Google's 2011 study found WebP files 25–34% smaller than JPEG at comparable SSIM quality on its test sets; today's browser encoders and your own image can differ. Try AVIF too when your browser can encode it. PNG is usually the one to beat for sharp text, flat colors and pixel art, especially with a reduced palette. JPEG suits opaque photos when compatibility matters most, and can't keep transparency: this tool fills transparent areas with a color you pick.

A browser that displays a format can't always encode it, so AVIF only appears here when yours can.

No. SVG is text, so data:image/svg+xml,%3Csvg ...%3E with URL encoding is valid and often shorter than Base64, whose payload overhead approaches a third. Encode at least %, # (as %23), <, > and double quotes.

This tool reads both forms, but the data URI it copies is always Base64. For SVG its real value is the cleanup: removing editor metadata, comments and unnecessary whitespace shortens either encoding while the image stays vector. Optional coordinate rounding shortens it further, but can move fine geometry.

Don't count on it. Support for images embedded as data: URIs is patchy across email clients, and several widely used ones block or strip them. Hosted HTTPS images, or MIME attachments referenced with a Content-ID (<img src="cid:logo">), are the usual alternatives, each with its own caveats: many clients hold back remote images until the reader allows them.

A MIME attachment encoded in Base64 is not the same thing as a data URI in the HTML. This tool can shrink the image and show its size, but it can't test deliverability: send a test to the clients your readers actually use.

Most likely a Content Security Policy. A directive such as img-src 'self' refuses data: URLs, so the image never loads and the browser console names the violated directive. If there is no img-src, default-src applies instead.

Add data: to the directive that governs the image, for example img-src 'self' data:, if that fits your site's policy, or serve the image as a regular file. Keep it to images: data: in script-src can let injected markup run code. And don't switch CSP off to fix one image.

The usual suspects: the string was cut while copying (a payload whose length, without padding, leaves one character over a multiple of 4 is a giveaway), it still carries JSON escapes such as \/ instead of / or a literal \n, it was URL-encoded (%2B for +), or a binary image data URI lacks ;base64.

This tool strips spaces, line breaks, quotes and url(...) wrappers, accepts the URL-safe alphabet (- and _), and selects the first character it can't read. Paste the image value rather than a whole JSON object. Valid Base64 can still hold a truncated file or something that isn't an image.

Often, as a hint: a PNG's Base64 starts with iVBORw0KGgo, a JPEG's with /9j/, a GIF's with R0lGOD. The prefix isn't proof, though. UklGR only means a RIFF container, which WebP shares with WAV and AVI, and an SVG can begin with an XML declaration, a comment or whitespace. That's why this tool checks the decoded bytes.

It can. Lower quality, fewer palette colors and smaller dimensions all remove detail, and Auto may pick a lossy format. The lossless PNG path keeps the pixels the browser decoded, not the original file's structure, metadata or color profile; canvas decoding can also nudge colors, through color conversion and rounding on semi-transparent pixels.

Re-encoding an animated GIF, WebP or PNG keeps a single frame, and the tool warns you when that happens. SVG cleanup rewrites the markup, and rounding coordinates can move fine geometry. When the exact file matters, copy or download the original.

Nothing is uploaded: decoding, previews and compression run in your browser, with the heavy lifting in a background worker, and no account is needed. Once the page and its worker have loaded, processing works offline.

Image files up to 25 MB can be imported. Very large images still need memory to decode, so a big photo can take a few seconds to compress. Keep in mind that a copied data URI puts the whole image on your clipboard, and embedding it in a public page publishes it.