Encode a PNG, JPEG, WebP, GIF, AVIF, BMP, or ICO file as a Base64 data URI. The format is read from the file's own bytes, the result is previewed from the URI it produced, and the size premium is measured rather than assumed.
Nothing loaded yet
Or paste one from the clipboard with ⌘V / Ctrl+V. PNG, JPEG, WebP, GIF, AVIF, BMP, ICO and SVG are recognised from their own bytes, not from the file name.
10 MB maximum · one image at a time · never uploaded
Each format below has a signature in its first bytes, and that is what decides the media type in your URI. A PNG someone renamed to .jpg is encoded as a PNG, because declaring the wrong type produces a URI that renders in one browser and quietly fails in the next.
The image below is loaded from the encoded string itself, on a checkerboard so transparency is visible. If it draws here, it will draw in your page.
Load an image and it appears here, rendered from the exact string the copy buttons hand you.
Encoding always works. Whether it should be done is a different question, and the answer follows from how big the finished string is and what it does to the file it lands in.
Load an image and the verdict appears here, banded by the size of the finished URI rather than the size of the file.
An inlined image has no URL, and everything the platform offers for images addresses a URL: srcset and sizes, loading="lazy", fetchpriority, preload, and a CDN that can resize on request. Inside a string, none of them apply.
A file is cached once and reused until it changes. An inlined image is cached only as part of its host file, so editing one CSS rule re-sends every image in that stylesheet, and referencing the same asset twice ships it twice.
Text compresses well, but Base64 of an already-compressed PNG or JPEG does not: the source bytes are near random, and the encoder adds a third before gzip ever sees them. Expect to recover a couple of percent, not the premium.
A long payload is shown with its middle removed so the page stays usable. Every copy button hands over the complete string.
Load an image and five copy-ready outputs appear here: the data URI, the raw Base64 payload, a background-image declaration, an image tag with its pixel size filled in, and a Markdown image.
Vector artwork is text: URL-encoding keeps it readable and close to its original size instead of adding a third.
Encode a font, an archive, or plain text, or decode a Base64 string somebody has handed you.
Shrink the source first; every byte removed before encoding is 1.33 fewer bytes in the finished string.
A data URI carries the whole file inside the reference, so the markup that names the image already contains it. For a binary format that means Base64: three bytes become four printable characters, a flat third of growth in exchange for a string that survives any stylesheet, template, or JSON field without further escaping. This page reads the file in your browser, identifies it from its own leading bytes rather than its name, renders the result from the URI it produced, and then tells you honestly whether the trade is worth making for this particular image.
Drop a file onto the panel, choose one from the picker, or paste a screenshot straight from the clipboard. It is read in this tab, and the 10 MB ceiling keeps the encoded string a size a browser can still work with.
The header is matched against the signature of each supported format, so a renamed file is still encoded as what it really is. The preview is then drawn from the generated URI, which is where a truncated download gives itself away.
The full data URI, the raw Base64 payload, a background-image declaration, an image tag carrying the decoded pixel size, or a Markdown image. The verdict beside them says whether inlining this particular file is a good idea.
Every supported format is identified by its magic bytes rather than its extension or the type the browser guessed. It matters because a wrong media type in a data URI does not throw; it renders in one browser and draws nothing in the next.
Four characters per three bytes, plus up to two padding characters, plus the prefix. The panel names each of those separately for the file you loaded, so the number is arithmetic you can check rather than a remembered third.
Under a kilobyte, inlining removes a request that costs more than the payload. Past forty, it is inflating a render-blocking file to save one parallel download. Each band comes with the reasoning, so you can disagree with it knowingly.
The preview loads the encoded URI itself onto a checkerboard, so transparency is visible and a corrupt file fails here instead of in production. Its decoded pixel size is written into the image tag to stop the layout shifting.
Unsupported files are identified rather than rejected blankly, because knowing you handed over a HEIC (which no browser can draw) is the difference between converting it and staring at an empty box.
The file is read with the browser's own File API and encoded from those bytes in memory. There is no upload, no queue, no request, and no retention, so an unreleased asset stays on your machine.
It is the entire file rewritten as a URL. The string opens with data:image/png;base64, and everything after the comma is the file's bytes spelled out in the 64-character alphabet of letters, digits, plus, and slash. Because the picture travels inside the reference, whatever loaded the stylesheet or the HTML already has the image, and no second request is made for it.
Because the bytes are binary. Percent-encoding leaves printable ASCII alone and spends three characters on everything else, which is a bargain for markup and a disaster for a PNG: compressed image data is close to random, so nearly every byte would need escaping and the string would land near triple the file size. Base64 charges a flat four characters per three bytes whatever the content, and its alphabet needs no further escaping in CSS, HTML, or JSON. For text-based SVG the trade reverses, which is why that format has its own page here.
For one small asset on the critical path, usually yes: a request has fixed costs in connection setup, headers, and latency that dwarf a 600-byte icon. Beyond that the answer turns negative quickly. The bytes join a file that blocks rendering, they are re-downloaded whenever that file changes, they cannot be lazy-loaded or deprioritised, and they cannot be fetched in parallel the way a separate URL would be. Inlining trades a request for weight in the wrong place; it only pays while the weight is trivial.
The payload is ceil(bytes / 3) × 4 characters (a flat 33.3% before rounding) plus the padding needed to reach a multiple of four, plus the roughly twenty-byte data:…;base64, prefix. A 10 KB PNG becomes about 13.4 KB of text. Compression does not rescue it either: gzip and brotli work on repetition, and an already-compressed image has almost none left, so you recover a couple of percent rather than the premium.
PNG, JPEG, WebP, GIF, AVIF, BMP, and ICO all encode and render as data URIs, and SVG is accepted here too though it belongs on the SVG page. HEIC is the notable refusal: it is what an iPhone saves by default and no browser can decode it, so encoding one would only produce a URI that renders nowhere. TIFF, PDF, and raw camera files are the same story. Convert them to PNG or JPEG first and encode the result.
The bytes are. Extensions are a naming convention that anyone can change, and files get renamed constantly: a PNG screenshot saved as .jpg, a WebP downloaded with a .png suffix. Every image format begins with a fixed signature, so the header is authoritative and it is what this page uses. If you write the extension's media type into the URI instead, browsers disagree about whether to sniff the content or trust the declaration, which is how an image ends up rendering on your machine and not on someone else's.
As a favicon, yes: <link rel="icon" href="data:image/png;base64,…"> works in every current browser and saves a request on first paint. Email is the opposite: Outlook ignores data URIs outright and Gmail strips them, so embedded images in email still need a CID attachment or a hosted URL. Also worth knowing: browsers have blocked top-level navigation to data: URLs since 2017, so pasting one into the address bar to check it will not work. Use the preview above instead.
Not a meaningful one in modern browsers: a data URI of several megabytes will load from a stylesheet or an image tag. The limits that bite are practical. This page caps input at 10 MB because the encoded string has to live in the tab's memory and in the DOM. Beyond that, minified bundles and source maps become unreadable, some CMS and database fields silently truncate long values, DevTools grinds when you inspect the element, and every kilobyte is re-sent with the file it lives in.
Explore the growing collection for calculations, documents, writing, and everyday work.