Base64 encoding turns binary data into text, which lets you embed an image directly inside HTML, CSS, JSON or an email rather than linking to a separate file. It is a genuinely useful technique that is also frequently misapplied.
Encoding something
Encoding and decoding both happen in your browser, so API keys, certificates and private assets are not sent anywhere.
The cost, up front
Base64 makes data about 33% larger. Three bytes of binary become four characters of text. That is inherent to the encoding and no tool avoids it.
So a 30KB PNG becomes roughly 40KB of text in your stylesheet. Whether that trade is worth it depends entirely on what you gain.
Where it genuinely helps
Tiny assets in CSS. An icon, a small texture, a 1px gradient. Under about 2KB, the encoding overhead is smaller than the cost of a separate HTTP request — the round trip, the headers, the connection setup. Embedding is faster.
Images in HTML email. This is the strongest case. Email clients block external images by default, so a linked image shows as a broken placeholder until the recipient clicks "show images". A base64 data URI renders immediately. For a logo in a signature or a transactional email, this is the difference between your email looking right and looking broken.
Note that Gmail historically stripped data URIs in some contexts, and support varies. Test in the clients you care about.
Self-contained files. A single HTML file that must work with no network — an offline report, a document sent as an attachment, a page inside a restricted environment. Embedding everything means it works anywhere with no missing assets.
Where it hurts
Large images. Encoding a 500KB photograph produces 670KB of text that has to be parsed as part of your HTML or CSS. Worse, it cannot be cached separately — every page load re-downloads it as part of the document, whereas a linked image is cached once and reused.
Anything used on multiple pages. A linked logo is downloaded once and cached for the whole site. A base64 logo is embedded in every page's HTML and re-downloaded every time.
Content that changes. Updating an embedded image means editing and redeploying the file that contains it.
Anything you want a CDN to serve. Embedded images cannot be served from an edge cache, resized on the fly, or converted to WebP by an image service.
The rough rule
Embed if the asset is small, used in one place, and must load without a separate request. Link everything else.
In numbers: under 2KB is usually worth embedding, 2-10KB is a judgement call, over 10KB should almost always be a linked file. Email is the exception where larger embeds are justified because the alternative is a blocked image.
Data URI syntax
The encoded string needs a prefix to be usable:
data:image/png;base64,iVBORw0KGgo...
The MIME type must match the file — image/png, image/jpeg, image/svg+xml, font/woff2. Getting it wrong is the most common reason an embed silently fails to render.
For SVG specifically, consider URL-encoding rather than base64. SVG is text already, so base64 adds 33% for nothing; a URL-encoded SVG data URI is smaller and works the same way.
Base64 is not encryption
Worth stating plainly because it is a recurring misunderstanding. Base64 is an encoding, not a cipher. Anyone can decode it instantly — including with the tool above. It provides zero confidentiality.
It appears in authentication headers because HTTP headers need text-safe values, not because it protects anything. An API key in a base64 string in your frontend JavaScript is exactly as exposed as one in plain text.