Image to Base64 & Base64 to Image

It's a way to convert binary image bytes into ASCII text. The encoder takes 3 bytes of raw image data, splits them into four 6-bit chunks, and maps each chunk to a printable character from a 64-character alphabet (A-Z, a-z, 0-9, plus, slash). The result is text-safe data you can drop into HTML, CSS, JSON, email body, anywhere binary would break things. The image isn't compressed or transformed - it's just dressed up in a text format. Decode it later and you get the exact bytes back. Useful, but it bloats size by about 33%.

Run the image through the converter and choose Data URI output - that wraps the Base64 string with the proper data:image/jpeg;base64, prefix. Copy the full string and paste it into your img src attribute: <img src='data:image/png;base64,iVBORw0KGgo...'/>. The browser decodes it inline, no separate HTTP request needed. Works the same way in CSS for background-image: url(data:image/png;base64,...). Best for tiny icons, single-file demos, or email signatures. For anything bigger than a few KB, just use a regular file - data URIs balloon HTML size and slow down rendering.

A data URI is a URL scheme that embeds the data inline rather than pointing to an external file. The format is data:[mediatype];base64,[encoded data]. So data:image/png;base64,iVBOR... tells the browser 'this is a PNG, encoded in Base64, here it is right here.' Browsers, email clients and many other tools recognize it and decode on the fly. No HTTP request, no separate file fetch. The trade-off: the encoded data lives inside the HTML or CSS file, making those documents larger. Great for tiny assets, terrible for large images. Browsers cap it at a few MB anyway.

It's the math of the encoding. Base64 represents every 3 bytes of binary as 4 ASCII characters - so the encoded text is always 4/3 the size of the original, roughly 33% bigger. A 100KB JPG becomes about 133KB of Base64 text. Then if you wrap it in JSON or HTML with quotes and attributes, add a bit more. There's no compression happening - quite the opposite, you're trading binary efficiency for text safety. That's why Base64 is great for inline icons or transport over text-only channels, but a poor choice for sending lots of imagery.

Reach for it sparingly, for specific cases. Tiny icons or sprites under 2-3KB where saving an HTTP request actually helps. Email templates, since attached images often render unreliably across clients but inline data URIs sometimes do better. JSON API payloads where you're shipping a thumbnail along with metadata. Single-file demos or self-contained HTML reports where you don't want to manage external assets. Avoid it for hero images, photo galleries, anything large - the 33% size overhead and the loss of browser caching outweigh the saved request. Files belong on the file system in most cases.

Often yes, but with caveats. Most modern email clients - Apple Mail, modern Outlook, web-based Gmail - render data URIs fine. Older Outlook versions and some corporate email systems strip or block them. There's also a hard size constraint: most providers limit total HTML body size to around 100KB, and Base64 encoding makes images 33% larger, so you can blow that limit fast. Spam filters sometimes flag emails heavy with inline data URIs as suspicious, hurting deliverability. For a small inline logo, data URI works. For anything bigger, host the image and use a regular img src URL.

No - it does the opposite. Base64 is purely an encoding scheme, not a compression algorithm. It takes binary data and represents it as text using a 64-character alphabet, producing output that's about 33% bigger than the input. There's no clever packing or reduction happening anywhere. If file size matters, compress the image first - run it through JPG quality 80 or convert to WebP - and then encode the smaller result to Base64. Encoding an already-large PNG to Base64 just gives you a larger headache. Compression and encoding are separate steps that solve separate problems.

Paste the string into the decoder. Two valid forms work: the full data URI (data:image/png;base64,iVBOR...) which the tool reads automatically, or the raw Base64 portion (just iVBOR...) where you might need to specify the format manually. The decoder reverses the encoding - turns the text back into the original binary bytes - and offers a preview plus a download button. The recovered file is byte-identical to the source that was originally encoded. If decoding fails, the string is usually truncated, contains invalid characters, or got corrupted in transit through chat or email.