Practical notes on inlining small assets, size tradeoffs, and how our tools help you convert without uploading files to a server.
Try the tool: Image to Base64 converter
Images on the web are bytes. A data URL wraps those bytes in a string like data:image/png;base64,.... so you can inline small assets in HTML, CSS, or tests without a separate fetch. The Base64 portion is the image bytes, not the pixels as “text,” so the string grows versus raw binary—plan for size when inlining large photos.
Our Image to Base64 tool produces those strings from local files in the browser, and Base64 to image helps you preview and normalize payloads you already have.
Great for tiny icons, email-safe snippets, and offline demos. Poor fit for big hero images, where a CDN, responsive sources, and caching win. If SEO is the goal, prefer normal image URLs in content so crawlers and social previews can fetch metadata the way they expect.
A minimal pattern is data:[mediatype][;base64],data. The mediatype should match the real bytes (e.g. image/png). Some systems omit ;base64 for percent-encoded text bodies; for images you almost always want the base64 form if you are embedding long binary in HTML.
Base64 inflates size versus raw bytes. Inlined images live inside your HTML or CSS, so the browser cannot cache them as separate resources with a long Cache-Control. Large inlines can delay first paint. Measure LCP, JS bundle and HTML size, and total bytes over the wire before inlining non-trivial art.
Output length (ignoring the data: prefix) is about ceil(n/3) × 4 character positions for the Base64 body, where n is the input byte size. That is a ~33% expansion before any UTF-8 URL escaping if you shove a data URL in JSON.
srcset / picture