A Base64 data URL lets an image travel inside a text document. Instead of a separate file request, the image bytes become a long string in the HTML, CSS or JSON. That can simplify a single-file demo or a small icon, and it can also bloat a page, break caching and leak metadata. The decision is less about whether the conversion works and more about whether inlining is appropriate for this particular image.
Part of the image optimization guide. The local image to Base64 tool converts a file into a data URL and previews a pasted data URL. It does not compress, resize or strip metadata, so it should not be the last step before publishing a photo.
What a data URL contains
The format is data:image/png;base64,iVBORw0KGgo.... The first part declares the media type, then comes the Base64 marker, then the encoded bytes. A browser can use that string directly as an image source. The payload is ordinary Base64, not encryption and not compression. Anyone who can read the page can decode it.
Base64 represents every three bytes as four text characters, so the encoded payload is about one third larger than the binary file. A 100 KB image becomes roughly 133 KB of text before the prefix. That overhead applies whether the image is a tiny icon or a photograph, and the text does not compress as well as the original binary in a gzip or Brotli response.
There is no file name, no separate cache key and no independent HTTP response. The image lives or dies with the document that contains it. Updating the image means updating the document, and every visitor downloads the full string again unless the document itself is cached aggressively.
What the converter accepts
Encode mode reads a local file through the browser's FileReader. The file must be 10 MB or smaller and one of five types: JPEG, PNG, WebP, GIF or SVG. The result is a complete data URL, ready to copy. There is no resize, no quality setting, no EXIF removal and no dimension check. A 9000-pixel image that passes the size limit will still produce a very long string.
Decode mode expects a full image data URL, not raw Base64. It accepts a preview allowlist that includes PNG, JPEG, GIF, WebP, SVG, BMP, AVIF and ICO, and it blocks obvious script and HTML payloads. The input is capped at 15,000,000 characters. Decoding shows a preview; it does not download a reconstructed file. To save the image, use the browser's image save command or decode the payload with a local script.
The asymmetry is intentional but easy to miss. The encoder accepts fewer types than the decoder can preview. If you have a BMP or AVIF file, convert it to PNG or WebP first. If you paste raw Base64 without the data:image/...;base64, prefix, the preview will reject it even though the characters are valid Base64.
| Operation | Limit or rule |
|---|---|
| Encode file size | 10 MB maximum |
| Encode types | JPEG, PNG, WebP, GIF, SVG |
| Decode input | Full data URL, 15,000,000 characters maximum |
| Decode preview types | PNG, JPEG, GIF, WebP, SVG, BMP, AVIF, ICO |
| Compression | None |
| Metadata removal | None |
| Download button | None; preview only |
Doing the size math before you inline
A 10 KB icon becomes about 13.3 KB of text. A 100 KB illustration becomes about 133 KB. A 1 MB photo becomes about 1.33 MB. Add the prefix and the surrounding HTML, then compare that with a separate image request that can be cached, compressed and served from a CDN. For a single small icon used once, inlining can remove a request. For a photo used on every page, it usually makes the page heavier and less cacheable.
The break-even point depends on the connection, the cache hit rate and the number of pages that share the image. An image used once on a rarely visited page may be fine inline. An image used in a header on every page should be a separate file with a long cache lifetime. Measure the actual page weight rather than guessing from the file size alone.
Base64 also affects HTML parsing and memory. A very long attribute or text node is more expensive to parse than a URL, and editing a document with megabytes of encoded image is unpleasant. Keep inline images small, and move anything approaching a few hundred kilobytes to a normal file.
When inlining helps, and when it hurts
Good candidates are small SVG icons, a single-file HTML report, a tiny CSS background used on one page, or an email template that must survive a strict content security policy. Even then, test the final environment. Many email clients block or strip data URL images, and corporate gateways may rewrite them. A preview in one client is not proof that every recipient will see the image.
Poor candidates are photographs, hero images, product galleries and anything reused across pages. They benefit from separate requests, responsive sources, modern formats and CDN caching. Inlining also makes responsive images harder because you cannot use srcset with the same ease, and it can duplicate the payload if the same image appears in several components.
Content Security Policy adds another constraint. If the page uses a strict img-src directive, data URLs need to be allowed explicitly. Allowing data: broadly can weaken the policy, so scope it to images if possible. Test with the production policy, not just a local development server.
Metadata and SVG risks
Converting a photo to Base64 does not remove EXIF data. GPS coordinates, camera model, timestamps and orientation can all survive inside the encoded string. If the image is going public, strip metadata with an image editor or a dedicated EXIF tool before encoding. The converter's preview is not a privacy filter.
SVG is text and can contain scripts, event handlers and external references. The decoder's allowlist and the way an image is used affect the risk. An SVG loaded through an <img> element has a restricted scripting model, while SVG inlined into the page is part of the document. Treat user-supplied SVG as untrusted, and do not paste an unknown data URL into a context where it becomes active markup.
The converter checks the declared media type and blocks obvious script prefixes, but it does not sanitize the SVG contents. That is enough for a preview of your own file, not for a public upload pipeline.
A practical inlining workflow
- Resize and compress the image first; the converter does neither.
- Strip EXIF and other metadata if the image will be public.
- Encode the optimized file and check the resulting string length.
- Confirm the destination supports data URLs, especially if it is an email client or a CMS.
- Update the CSP if needed, scoped to images rather than all content.
- Measure the page before and after; remove the inline image if it makes the critical path heavier.
For a separate-file workflow, see the format comparison and the EXIF guide. For the text encoding layer, the Base64 modes guide explains why URL-safe alphabets differ from the standard one used in data URLs.