Image to Base64
Two-way conversion between images and Base64 / Data URI — inline small icons or CSS backgrounds with one paste.
>_ USAGE GUIDE
Two-way conversion between images and Base64 / Data URI: drop in an image and receive the complete data:image/png;base64,... string — paste-ready for a CSS background-image, an HTML src, or a JS variable. The reverse direction takes a Base64 string, previews the image instantly, and offers a download.
- Drop the image in: the Data URI string appears immediately with the correct MIME prefix
- Paste it into your code: CSS backgrounds, inline
<img>, or email templates - Decode in reverse: paste a Base64 string to preview and download the image
Typical scenarios: inlining small icons on the front end to save a network request, embedding images in email templates (many clients require it), and dropping a background straight into CSS. A quick sanity rule before embedding: if the Data URI string is longer than the CSS rule that would load the file normally, linking the file is the better engineering choice. Conversion runs in the browser with zero uploads — images never leave your device.
>_ FAQ
Q1 · What are the pros and cons of embedding images as Base64?
Pros: no extra HTTP request, no 404 risk, single-file distribution (emails, offline pages). Cons: about 33% size inflation, no independent browser caching (only the host HTML/CSS gets cached), and an unreadable wall of characters in your source. Conclusion: small icons of a few KB embed well; large images should stay as files with proper caching.
Q2 · Can the Base64 string go straight into CSS?
Yes, in two forms: background-image: url("data:image/png;base64,xxxx") with the complete Data URI, or <img src="data:image/..."> in HTML. The MIME prefix must match the actual image format (png/jpeg/webp) — a mismatched prefix can make the browser refuse to render. This tool emits the correct prefix, so the output is copy-and-go.
Q3 · Why does the same image produce a different Base64 string each time?
Identical input bytes always produce identical Base64. If the output differs, the input bytes changed — commonly because the two files came from different saves (an editor re-encoded it) or a compressor touched one in between. Trust the file bytes, not your memory of the string.
Q4 · How much bigger does a Data URI get, and can it be optimized?
Base64 encodes 3 bytes as 4 characters — a 4/3, roughly 33% inflation. The optimization order matters: compress the source first with the Image Compressor (WebP often halves it), then convert — compress-then-embed is the minimal payload. An already-large Base64 string has no room left; go back and optimize the source image.
Q5 · The pasted Base64 will not preview — what is wrong?
Check in order: missing MIME prefix — add data:image/png;base64, (this tool also handles bare strings automatically); a prefix that does not match the actual format (says png, actually jpeg); a truncated string or one polluted with line breaks or spaces (some parsers are newline-sensitive); or lost == padding at the end from a partial copy. Re-copying the complete string usually fixes it in one shot.