Image to Base64
Convert PNG, JPG, WebP or GIF images into a Base64 data URI, plain Base64 string, HTML img tag or CSS background. Ideal for embedding small icons directly
Drop your image file here
or click to browse files
Turn a PNG, JPG, WebP, GIF or SVG into Base64 and get it in the form you actually need: a full data URI, a bare Base64 string, an HTML <img> tag or a CSS background declaration, ready to paste.
Embedding small graphics directly in code removes a network request and guarantees the icon appears even before the stylesheet loads - which is why data URIs are popular for icons, spinners and email signatures. The trade-off is size: Base64 is about a third larger than the binary file and cannot be cached separately, so keep it to small assets and link larger images normally.
How to convert an image to Base64
Choose an image
Pick the output format you need
Copy the data URI, tag or CSS
FAQ
When should I embed an image instead of linking it?
For small, frequently used graphics under roughly 10 KB - icons, logos, spinners - where saving a request matters more than the size increase. Large photos should stay as files so the browser can cache them.
Why is the Base64 string bigger than my file?
Base64 encodes every three bytes as four characters, which adds about 33%. That overhead is unavoidable in the encoding itself.
Which formats can I use?
PNG, JPG, WebP, GIF and SVG. Vector SVG embedded as a data URI stays scalable, so it is often the best choice for icons.
Does it work in CSS as well as HTML?
Yes, copy the CSS form to use it in a background-image declaration, or the HTML form for an img src attribute.
Will email clients display it?
Most modern clients do, but some strip data URIs for security. For email templates, host the image and link it if the layout matters.
Is my image uploaded?
No, the encoding happens in your browser.
At a glance
| Input | image |
|---|---|
| Multiple files | Yes |
| Where it runs | In your browser - files are never uploaded |
| Works offline | Yes — once the page has loaded |
| Price | Free, no sign-up, no watermark |
Where conversions quietly break
Most conversion bugs are not about syntax, they are about meaning. A CSV column of postcodes loses its leading zeros the moment a spreadsheet guesses it is a number; a long ID exceeds floating-point precision; dates change meaning depending on whether they are day-first or month-first. JSON keys are unordered but arrays are not, and a tool that sorts keys changes nothing while one that sorts arrays changes the data. Unicode is another trap: text can arrive as UTF-8, UTF-16 or with a byte-order mark, and a decoder that guesses wrong turns accented characters into mojibake. Before trusting any conversion, spot-check the first and last row, any field with leading zeros, and any field containing quotes, commas or newlines.
Choosing a data format
JSON is the default for anything an API returns or a program reads: it handles nested structures, numbers, booleans and null naturally, and every language parses it. CSV is smaller and opens straight into a spreadsheet, but it has no way to express nesting and no shared standard for the delimiter, quoting or character set - which is exactly where conversions go wrong. XML is verbose but carries attributes, mixed content and schemas, so it still dominates document formats and legacy integrations. YAML is the most readable for configuration but is whitespace-sensitive and has surprising type coercion ("no" becoming false, a version like 1.10 becoming 1.1). Pick the format the consuming tool prefers rather than the one that looks nicest.