What Base64 image encoding actually is
Base64 is a way of taking binary data — like an image file — and rewriting it as a long string of letters, numbers, plus signs, and slashes. The result looks like gibberish, but it can be embedded directly into text-based files: HTML, CSS, JSON, JavaScript, or email markup. Instead of saying "here's a link to a file the browser should download," you're saying "here's the entire file inlined right here in the page."
This sounds wasteful (and sometimes it is — more on that in a moment), but for certain use cases it's exactly what you want. A 200-byte icon embedded as a Base64 data URI loads at the same time as the HTML, without a separate HTTP request. An image baked into an email template displays the same way every time without depending on the recipient's email client successfully fetching it from your server. A logo embedded in an exported document remains visible even if the document is sent to someone offline.
This tool takes any image you give it and produces the Base64 string, ready to paste into your HTML, CSS, or JSON. It runs entirely in your browser — your image is never uploaded — which matters for unreleased branding, private assets, or anything you wouldn't want sitting on a stranger's server.
How to encode an image to Base64
Step 1 — Drop your image
Drag any common image format — JPG, PNG, WebP, GIF, SVG — into the upload area. Smaller images make smaller Base64 strings (that's important — see the "when not to use this" section below).
Step 2 — Pick your output format
The tool offers a few useful variants of the Base64 output: raw Base64 (just the encoded string), a complete data URI (the data:image/png;base64,... form ready to use in HTML or CSS), an HTML <img> tag with the data URI already inlined, and a CSS background-image snippet. Pick whichever fits where you're going to paste the result.
Step 3 — Copy and paste
Click copy. The encoded image is now on your clipboard. Paste it into your HTML, CSS, JSON config, or wherever you need an inlined image.
When Base64 encoding is the right choice
Very small images that load on every page. If you have a 1KB icon that appears in your site header on every page, inlining it as Base64 in your CSS removes one HTTP request per page load. For high-traffic sites, that's a real performance win.
Email templates. Email is the wild west — different clients handle external images differently, and many block remote images by default for privacy. Embedding small logos and icons as Base64 ensures they always display, regardless of the recipient's email client settings. (Note: this isn't a magic fix — some email clients also block Base64 images or convert them to attachments. Test in the clients your audience uses.)
Standalone HTML files. If you're sharing a single HTML file (a one-page report, a portfolio sample, a quick prototype), inlining the images means the file works standalone with no broken-image risk. The recipient gets one file, opens it, and everything's there.
Configuration files that include images. When you need an icon or thumbnail baked into a JSON config, Base64 is the canonical way to include binary data in a JSON-friendly format.
Quickly testing or sharing an asset. Need to paste an image into a Stack Overflow question or a chat without uploading it somewhere first? Base64 lets you drop the entire image inline as text.
Avoiding mixed-content warnings. If your page is served over HTTPS but you need to display images from an HTTP source, inlining them as Base64 dodges the mixed-content warnings browsers throw.
When Base64 is the wrong choice (and you'd be surprised how often)
Despite its uses, Base64 image encoding is overused and frequently misapplied. The honest truth: for most web images, a regular <img> tag pointing to a real file is faster, easier to cache, and easier to update. Specifically, don't use Base64 when:
- The image is large. Base64 inflates file size by about 33%. A 100KB PNG becomes a 133KB string of text. For a large image, that's a lot of extra bytes that have to be downloaded, parsed, and processed.
- The image is used on multiple pages. A separate image file gets cached by the browser after the first load. A Base64-encoded image embedded in your HTML or CSS is re-downloaded with every page that uses it, defeating the cache.
- The image might change. Updating a Base64-inlined image means redeploying the HTML/CSS file. Updating a separate file means swapping the file. The second is faster and easier.
- You're optimizing for page load speed. Most modern browsers handle parallel image downloads efficiently; the "save an HTTP request" argument is much weaker than it was a decade ago. Bundling images via HTTP/2 multiplexing or service workers is often a better optimization.
- The image is photographic. Large photos as Base64 are almost never a good idea — the file size overhead is significant and you lose all the caching benefits.
How to use the Base64 string once you have it
In HTML, paste the data URI as the src attribute of an <img> tag: <img src="data:image/png;base64,iVBORw0KGgo...">. The browser decodes the Base64 on the fly and renders the image just like a normal file-based image.
In CSS, use it as a background-image: background-image: url('data:image/png;base64,iVBORw0KGgo...');. Same deal — the image is rendered as if it were a normal background image file.
In JSON, store the string under whatever key your application expects: { "icon": "data:image/png;base64,iVBORw0KGgo..." }. Your application reads the value and uses it wherever.
In email templates, paste the full data URI as the src attribute exactly like you would for HTML. Test the result in the email clients your audience uses (Gmail, Outlook, Apple Mail, etc.) — Base64 support varies, and some clients strip or block it.
Performance reality check — what Base64 costs you
The cleanest way to think about Base64 for images: it trades caching efficiency for elimination of one HTTP request. That tradeoff is almost always a loss for large images and a small win for tiny images. The break-even point depends on your network, your users' devices, and your caching strategy — but as a rough rule, images under about 4KB are worth considering for Base64, images larger than that probably aren't.
The other cost is page weight. Browsers parse HTML linearly — if your HTML is 2MB because it has 1.5MB of inlined Base64 images, your page's initial render is delayed compared to a 50KB HTML page that references those images as separate files. Modern browsers stream-render HTML so the impact is smaller than it once was, but it's not zero.
If you're embedding images for performance reasons rather than aesthetic ones, measure first. Tools like Lighthouse, WebPageTest, and your browser's network panel will tell you whether Base64 is actually helping or hurting in your specific case.