Image Base64 Conversion Tool
Convert between images and Base64 encoding, supports drag-and-drop and real-time preview
Drag image here, or click to select file
Supports JPG, PNG, GIF, WebP, SVG and more
What is Base64 Image Encoding?
The Image Base64 tool converts image files into Base64 text or data URLs, and can decode those strings back into viewable images. It is handy for small icons, placeholders, email templates, CSS backgrounds, API tests, and demos where shipping a separate image file would be inconvenient. Base64 is not a compression format: it usually makes the payload larger and can hurt caching when used for large photos or repeated assets. This tool is best for quick conversion, inspection, and debugging while you decide whether embedded data, a CDN file, or a normal image URL is the better delivery method.
How to Use
How to use
- Drag or click to upload image, auto-detect type and dimensions
- Choose output format: Data URL (ready for code) or pure Base64
- Click the copy button to paste the encoded result where needed
- For reverse conversion, paste Base64 string and click convert to download image
Base64 to Image
- Paste a data URL or raw Base64 string into the input box, then convert it to preview the decoded image before downloading.
- If decoding fails, check that the Base64 text is complete and that any data:image/... prefix is correctly formed.
Image to Base64
- Choose Data URL when the result will be pasted directly into HTML or CSS, and choose pure Base64 when another system already stores the MIME type separately.
- Keep Base64 images small; large images increase text size by about one third and can make HTML, CSS, or JSON payloads harder to maintain.
Use Cases
Technical Principle
A Base64-encoded image is a data URI as defined in RFC 2397: the scheme prefix data:, the MIME type such as image/png, the literal ;base64, and then the payload built from the 64-character alphabet A-Z, a-z, 0-9, +, /, with = as terminal padding. Encoding takes the binary stream three bytes at a time and emits four characters, so the payload grows by a fixed factor of 4/3 (roughly 33%) plus one or two padding characters when the byte count is not a multiple of three. In the browser, encoding starts with FileReader.readAsDataURL, which streams the file through the same pipeline and returns the complete data: URL ready to drop into an <img src> or CSS background-image url(). The string-only btoa and atob primitives work on already-binary payloads (latin-1 only, so binary bytes must be converted via Uint8Array). Decoding back into a viewable image goes through atob into a Uint8Array, then into a Blob with the original MIME type, and the URL.createObjectURL handle becomes a normal HTTP-fetchable asset. The practical trade-off is not bandwidth but caching. Each occurrence of the payload is duplicated wherever the HTML, CSS, or JSON appears, so the asset cannot be cached separately, cannot get its own ETag, and re-downloads with every parent document. Strict Content-Security-Policy rules also block data: URIs unless 'data:' is explicitly listed under img-src or style-src. Since HTTP/2 multiplexing landed, inlining small icons rarely beats a separate request, so the modern rule of thumb is to inline only under ~2 KB and to keep hero images and reusable sprites as cacheable files.
- Data URI scheme: RFC 2397 format data:[<mime>][;base64],<payload>; the comma is required and is the most common copy-paste failure.
- Encoding overhead: 3 binary bytes become 4 ASCII characters, so the payload grows by a factor of 4/3 (~33%) plus up to 2 '=' padding characters.
- Browser APIs: FileReader.readAsDataURL for files; btoa/atob for already-text payloads (latin-1 only, so binary needs a Uint8Array bridge).
- Decode path: atob → Uint8Array → new Blob([buf], {type}) → URL.createObjectURL gives a normal fetchable asset URL instead of a frozen string.
- CSP gotcha: a strict img-src or default-src policy blocks data: unless the keyword is explicitly listed, which silently breaks inlined images in production.
- Caching trade-off: inlined data has no independent ETag or cache entry, so HTTP/2 multiplexing usually beats inlining for anything above ~2 KB.
Examples
Use in HTML
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII=" alt="1x1 transparent pixel" width="16" height="16" />Use in CSS
.icon-search {
width: 16px;
height: 16px;
background-image: url('data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAxNiAxNiI+PHBhdGggZD0iTTYgMmE0IDQgMCAxIDAgMi4yNCA3LjMzbDMuMjEgMy4yMSAxLjQyLTEuNDItMy4yMS0zLjIxQTQgNCAwIDAgMCA2IDJ6Ii8+PC9zdmc+');
background-size: contain;
}Transmit in JSON API
POST /api/v1/avatar
Content-Type: application/json
{
"userId": 10086,
"avatar": {
"mimeType": "image/png",
"data": "iVBORw0KGgoAAAANSUhEUgAAAAUA..."
}
}
// Note: Base64 inflates payload by ~33%; for files > 100KB prefer multipart/form-data.FAQ
Is the image uploaded?
No. The image is read with the FileReader API and Base64-encoded in your browser. The bytes never leave your device. Watch the Network tab during conversion to confirm.
Why is the Base64 string ~33% longer than the file?
Base64 represents 3 input bytes as 4 ASCII characters, so encoded size = ceil(file_size / 3) * 4. That's about 33% overhead, the cost of representing binary as printable text.
How do I use the result in HTML or CSS?
Use a data URI: <img src="data:image/png;base64,..."> in HTML or background-image: url(data:image/png;base64,...) in CSS. The page generates the full data: URI for you. Useful for tiny inline assets, but inflates HTML/CSS file size and bypasses browser image caching.
What's the size cutoff for inlining vs. linking?
Below ~5 KB, inlining usually wins (saves an HTTP request). Above that, the file should be a separate asset for caching reasons. Above ~50 KB, inlining significantly bloats your HTML. Different build tools use different thresholds; webpack defaults to 8 KB.
Can I decode a Base64 string back to an image?
Yes. Paste a data: URI or raw Base64 (with image/* mime type) and the page reconstructs the image and offers download. Useful when you find an inlined image in source code and want the original file.
Are SVG and animated GIFs supported?
Yes. SVG can be encoded directly or with URL-encoded text (which is shorter than Base64 for SVG-XML). Animated GIFs encode as a single Base64 string; the result still animates. WebP, AVIF, and other modern formats work the same way.
Should I Base64-encode large photos for emails?
Email itself MIME-encodes attachments in Base64 anyway, so you don't need to pre-encode them. Pasting a Base64 string into the email body just makes the message bigger and unreadable for most clients. Attach the file normally.