Image to Base64
Convert any image to a Base64 data URI - instantly, in your browser. No uploads, no servers.
Drop image(s) here
PNG, JPG, GIF, WebP, SVG, BMP, ICO, AVIF - any image format
Browse filesHow to use
- Drop your image onto the upload area, or click to pick a file.
- The image is converted to Base64 instantly in your browser.
- Copy the data URL or just the Base64 payload.
- Use the size preview to check the encoded length before embedding.
- Switch between data URL and raw modes depending on where you will paste it.
Frequently asked questions
Is my image uploaded anywhere?
No. The conversion happens entirely in your browser using the FileReader API. The bytes never leave your device.
When should I embed images as Base64?
For small icons, logos, or tracking pixels under about 4 KB. Above that, the 33% size penalty and lack of caching usually outweigh the saved HTTP request.
What file types are supported?
Anything the browser can read, including PNG, JPG, WebP, GIF, SVG, BMP, and ICO. Output format follows the input MIME type.
Why is the Base64 string so much longer than the file?
Base64 represents every 3 bytes with 4 characters, so encoded output is roughly 33% larger than the binary file size, plus a small MIME prefix.
What embedding an image as text buys you, and what it costs
A data URI (data:image/png;base64,...) folds an image's bytes directly into HTML, CSS or JSON as Base64 text. The benefit is the elimination of an HTTP request and of any external file dependency: the document becomes fully self-contained. The costs are concrete: Base64 inflates size by 33%, the embedded image cannot be cached separately from the document carrying it, and a large blob of text in your markup makes files unwieldy to edit and diff. These trade-offs define exactly when the technique is appropriate.
Good and bad candidates
- Good: tiny icons and decorations under ~5 KB, images inside self-contained HTML email templates, single-file reports or prototypes, favicons, image data inside JSON APIs and canvas/clipboard workflows.
- Bad: photos and hero images (a 300 KB JPEG becomes 400 KB of uncacheable text), any image reused across multiple pages (each copy re-downloads), and anything a CDN should serve.
- A useful threshold: if the file exceeds roughly 10 KB, link it; below that, embedding is defensible.
Mechanics worth knowing
The MIME type in the prefix must match the actual format... image/png, image/jpeg, image/webp, or image/svg+xml... or some browsers refuse to render. SVG is a special case: being text already, it can embed via URL-encoding instead of Base64, often more compactly. In CSS, wrap the URI in url('...'); in HTML it drops straight into an src attribute. The conversion is trivially reversible, which is also the reminder that embedding provides zero protection for the image itself.
Reversing the direction: from Base64 back to a file
The conversion runs both ways, and the reverse direction has its own use cases. Image data arrives embedded in API responses, exported JSON backups, email source and saved web pages; decoding it back to a real file recovers the original bytes exactly... Base64 is lossless transport, so nothing was degraded by the round trip. The prefix tells you what you are recovering before you decode: iVBOR begins every PNG, /9j/ every JPEG, R0lGOD a GIF, PHN2Zy an SVG. A decode producing a file that will not open usually means the string was truncated in transit... check that its length is a multiple of four and the padding survived.
Advertisement