Drop an image file to encode it as Base64 — useful for embedding images directly in HTML, CSS, JSON, or email. Choose standard Base64, URL-safe, or a ready-to-paste data: URI.
Embedding small images via Base64 saves an HTTP round-trip but adds 33% size and loses caching. Good for icons under 1 KB; bad for anything over 4 KB. For SVG specifically, prefer the URL-encoded form — it produces smaller output than Base64 for text-based formats.
For very small images (under 4 KB) used inline in CSS, HTML, or email. Above 4 KB, the size penalty of Base64 (33% larger) and the loss of browser caching usually outweigh the saved HTTP request. Common good uses: small icons, signature images in emails, single-use illustrations in PDFs.
No. The browser reads the file using the FileReader API, encodes it locally, and shows the result. No part of the file leaves your device. You can verify this by disabling your network in DevTools and the tool still works.
Some email clients (notably older Outlook versions) block data URIs as a security measure. For email images, attaching as a CID reference or hosting on a public URL is more reliable than inline Base64.
Base64 represents 3 binary bytes with 4 ASCII characters — a 33% inflation. A 1 MB image becomes about 1.33 MB of Base64. Plus you typically need to wrap it in a data URI ("data:image/png;base64,") which adds a small prefix.
The classical guidance for inlining images as Base64 data URIs is the 4 KB rule: images smaller than 4 KB usually benefit from inlining, images larger than 4 KB usually do not. The reasoning is simple — each separate HTTP request has overhead (DNS lookup, TCP handshake, TLS negotiation, headers) that varies from about 50 to 200 ms on typical connections. For tiny files, this overhead dominates the download time, so eliminating the request via inlining is a net win. For larger files, the request overhead is small relative to the download size, and the 33% inflation from Base64 becomes the dominant cost.
HTTP/2 and HTTP/3 reduce the per-request overhead significantly through multiplexing — multiple resources can share a single connection. This raises the inlining threshold somewhat, but the basic intuition still holds: tiny images inline well, large images do not.
Email signature images. Email clients often block externally-hosted images for privacy reasons. Inlining the signature as Base64 ensures it always displays. The added bytes (typical signature: 5–10 KB) are sent once per email, which is fine.
Small CSS background icons. If you have a 200-byte arrow icon used 50 times in your UI, inlining it eliminates 50 HTTP requests in exchange for a one-time 270-byte (Base64-inflated) addition to the CSS file. Worthwhile.
Single-file HTML reports. When generating an HTML document that needs to work offline or be emailed as a single attachment, inlining all images is the only option. PDFs work better for this, but HTML is sometimes required.
Configuration files with embedded images. Some tools accept configuration in YAML or JSON with embedded thumbnails or logos. Base64 is the standard format.
Hero images and large photos. A 500 KB hero photo becomes 670 KB of Base64. You lose browser caching (each page download re-fetches the data), you cannot serve responsive variants, and the HTML/CSS file balloons.
Repeated images. Inlining means the bytes are embedded everywhere the image appears. A 10 KB logo used on 20 pages costs 200 KB of duplicated bytes — versus 10 KB cached once when served as a separate file.
Images you want to lazy-load. Browser native lazy loading (loading="lazy") does not work for inline images. If a user scrolls past your image, the bytes were transferred anyway.
This tool offers four output variants. Standard Base64 (with padding) is the universal choice and what most APIs and CSS parsers expect. URL-safe Base64 (with - and _ instead of + and /) is needed when the encoded string will appear in a URL or filename — but most CSS data URIs use standard Base64 even inside url() values, so URL-safe is rarely needed for image embedding. URL-safe, no padding drops the trailing = characters — typical for JWT-like systems but not for general image embedding. MIME (76-character line wrap) breaks the output into 76-character lines, required by older email systems and some legacy parsers; modern HTML and CSS accept unwrapped data URIs without issue.
For an HTML img tag or CSS background-image, choose Standard Base64. For an email attachment in a MIME message, choose MIME. For everything else, Standard Base64 is the safe default.