Image to Base64 Converter
Convert an image to a Base64 data URI in your browser - copy it for HTML, CSS, or JSON.
- Free, no account
- No watermark
- No usage limit
About the Image to Base64
Getting the Base64 string is the easy part. Any converter can hand you a wall of encoded text. The annoying part is everything after: figuring out how that string has to be wrapped for wherever it's going. CSS wants it inside url() with quotes around it. A JSON field or a database column usually wants the prefix chopped off and just the raw payload. An HTML image wants the whole data: URI sitting in its src. Get the wrapper wrong and the image quietly fails to render, no error message, nothing to point at. This tool hands you all four forms with one click each, so you copy the exact shape the destination expects instead of hand-editing a giant string and hoping you got it right.
And the picture never leaves your machine. Plenty of the free encoders online push the file you drop in up to their server to do the encoding. This one reads and encodes it right in your browser, so a logo you haven't shipped yet, a client's asset, a screenshot you'd rather not hand to a stranger, none of it goes anywhere. Drop a file on the box and you get the full data URI plus the ready-to-paste snippets. Close the tab and it's gone, nothing saved.
How to use
- Add your image. Drag a file onto the dashed box, or click it to open your file browser and pick a PNG, JPG, GIF, SVG, or WebP.
- Check the preview. A thumbnail shows up next to the file name, type, and size, so you can confirm you grabbed the right file before copying anything.
- Glance at the character count. It sits above the output box and updates the moment your image loads. That number is your quick read on whether this image is small enough to inline (more on that below).
- Copy the form you need. Four buttons: the full data URI, the raw payload with the prefix removed, a ready HTML image tag, or a CSS background rule. Pick the one that matches where you're pasting.
- Clear and go again. Hit Clear to drop the current image and encode another. Nothing carries over between files.
Which copy button you actually want
Most converters stop at the raw string and leave the wrapping to you. Picking the right form for the destination is where the time goes, and picking wrong is a common way to lose an afternoon. The same encoded image gets shaped four different ways here.
Copy data URI gives you the complete data:image/png;base64,... string. This is the default for HTML, anywhere a browser expects an image URL. It drops straight into the src of an image element or a CSS url().
Copy raw base64 is that same encoded data with the data:image/png;base64, prefix stripped off, leaving only the payload after the comma. That's the version you want when a system stores the encoding and the media type in separate fields, like a JSON API body or a database column. Pasting the full data URI into one of those is a classic mistake, you end up with the scheme doubled up or the decode failing outright.
Copy as image tag builds a full HTML image element with the data URI already dropped into the src and your file name filled in as the alt text. Paste it into a page and it renders as-is.
Copy as CSS background writes a background-image rule with the URI wrapped in quotes for you. The quotes are the part people forget, an unquoted data URI can trip the CSS parser on certain characters, so having them pre-added saves a genuine bug.
Base64 itself is just a way of rewriting binary data using plain text characters, which is how an image can ride along inside a stylesheet, a config file, or an email body that only understands text. The encoding loses nothing and runs both ways. Nothing gets recompressed or recolored, the bytes inside the string decode back to a file identical to the one you dropped in.
Is this image even worth inlining?
The one thing worth deciding before you paste is whether this image belongs inline at all. Base64 adds roughly a third to the size, because every three bytes of the original become four text characters. A 10 KB icon lands near 13 KB encoded. That's nothing for something tiny. For a photo it's real, pointless weight.
So it's a targeted move rather than something you reach for by default. Inlining pays off for small, frequently used assets where saving a network request beats a few extra bytes: a UI icon, a small logo, a repeated background texture, an image baked into an HTML email so it shows up even when the client blocks external images. It stops paying off fast for anything large. A big inline image can't be cached on its own, it re-downloads with every page that embeds it, and it bloats the HTML the browser has to parse before it can show anything. External files get cached once and reused everywhere, and they load in parallel.
The character count above the output box is the gauge for all of this. A few hundred characters, inline it without a second thought. Tens of thousands, that image wants to stay a linked file. If a graphic you genuinely need inline comes out too big, compress or resize it first, then encode the smaller version.
Frequently asked questions
My inline image shows up as a broken icon. What's wrong?
Usually the media type. If the prefix says image/jpeg but the file is really a PNG, the browser can't decode it and shows nothing, with no error thrown. Copying straight from here avoids that, because the tool reads your file's real type and writes the matching prefix for you. The other common cause is a strict Content Security Policy: inline images need img-src data: in the policy or the browser blocks them.
Can I convert an SVG this way, or is there a better option?
You can, and the tool handles SVG fine. But an SVG is already plain text, so Base64-encoding it throws away that advantage and makes it about a third larger for no reason. If you control the markup, pasting the raw SVG or using it inline stays smaller and keeps it editable and styleable with CSS. Reach for Base64 on an SVG only when a field specifically demands a data URI.
Does encoding lower my image quality?
No. Base64 is not compression and not a re-save. It rewrites the same bytes in a text-safe alphabet, so decoding hands you back a byte-for-byte identical file. Quality, dimensions, and format all stay untouched. The one thing that changes is that the data is now text instead of binary, and about a third bigger.
Can I turn a Base64 string back into an image here?
This tool goes one direction, image to Base64. For the reverse you'd paste the string into a Base64-to-image decoder instead. If you only need to eyeball what a data URI contains, pasting it into a browser's address bar renders it directly, which is a quick sanity check that the string is intact.
Will the same data URI work inside an email?
Sometimes, and it's worth testing before you send. Inlining is popular for email precisely because many clients block linked images, but a fair number of clients also strip data: image URIs for security, Outlook being the usual offender. If the message has to render everywhere, a hosted image or a CID attachment is the safer bet.
Why keep the prefix for HTML but strip it for JSON?
Because they're solving different problems. HTML and CSS need the full data URI so the browser knows the string is an image and how to decode it, and the prefix is what carries that. A JSON API or database that already stores the media type in its own field only wants the encoded bytes, so the prefix there is redundant or actively breaks the field's own parsing. That's the whole reason there are two separate copy buttons instead of one.