File to Base64
Encode any file to Base64 or a data: URI — an image gets HTML, CSS and Markdown snippets too — or decode one back to the original file, previewing pictures.
🔒 Everything runs in your browser — your file is never uploaded, and it works offline.
Drop any file here or click to browse
Encode and decode any file
Drop any file — an image, PDF, font, zip, or WASM module — and get its Base64 string and a ready-to-paste data: URI, each with a one-click copy and a .txt download. An image also gets the forms it is pasted into, beside a thumbnail: an HTML <img>, a CSS background-image, Markdown, a plain link, a link that downloads it and a favicon <link>. Switch to Decode to paste a Base64 string or data URI, or open the .txt it was saved in, and download it back as the original binary file; a picture is previewed first. Everything runs locally in your browser, so even large or sensitive files are never uploaded.
Base64 and data URIs
Base64 turns raw bytes into plain ASCII so binary data can travel safely through text-only channels such as JSON payloads, environment variables, or a source file. A data URI wraps that Base64 with its MIME type (data:image/png;base64,…) so it embeds directly in HTML, CSS, or Markdown with no separate request.
Frequently asked questions
How is this different from the Base Encoder?
The Base64 encoder next door is built around text — it can open a file too, but a smaller one, and it hands back the raw Base64 without a data: URI. This is the one for files: any file up to 10 MB — fonts, PDFs, archives, executables — encoded byte for byte into both a Base64 string and a data: URI carrying the right MIME type, and decoded back into a file you can download.
Are my files uploaded to a server?
No. Encoding and decoding run entirely in your browser with the FileReader and Blob APIs, so your files never leave your device and the tool works offline once the page has loaded.
Can I see a Base64 image before saving it, even without a data: prefix?
Yes. The type is read from the data: prefix, or without one from the bytes themselves — PNG, JPEG, GIF, WebP, BMP and SVG among them — and when it is an image the picture is previewed before you save it. If the type is wrong, pick another under MIME type; Copy as data URI then hands back the ready-to-embed string.
When should I not inline an image as a data URI?
For anything a browser would otherwise cache on its own, or anything above a couple of kilobytes. An embedded image is re-sent with every copy of the page and cannot be cached, lazy-loaded or swapped for a smaller variant.
My image data URI shows nothing on the page.
Check the Content-Security-Policy first: a policy without data: in img-src blocks it silently. After that, check the MIME type in the prefix matches the actual image format.