The one-fewer-request trick
Every separate image file on a page costs a network round trip to fetch — for a small icon or a tiny UI graphic used repeatedly, that round trip can genuinely cost more time than the image itself takes to transfer, especially on a slow connection. Base64 encoding sidesteps this entirely by turning the image's binary data into a plain-text string that gets embedded directly inside your HTML or CSS, so it loads as part of that file with zero extra requests.
This is exactly the technique behind a `data:image/png;base64,...` string sitting inside a stylesheet's `background-image` property, or an inline `<img src="data:...">` tag you might have seen in a page's source.
The 33% tax nobody mentions upfront
Base64 encoding isn't free — representing binary data as text-safe characters inherently takes about a third more space than the original file. For a tiny icon that's a rounding error. For anything larger, embedding it as Base64 directly bloats the HTML, CSS, or JSON file it's sitting inside, which can genuinely hurt page load performance since that inflated text now has to download before the rest of the page can render, rather than loading in parallel the way a separate image request would.
The practical rule: Base64 is a good trade for small, frequently-reused graphics. For anything that qualifies as an actual photo or a larger graphic, a normal separate image file with proper caching headers almost always wins.
Where this actually gets used in practice
Beyond web development, Base64 image strings show up in JSON API responses that need to include image data without a separate binary upload step, in email HTML where external images often get blocked by mail clients anyway, and in situations where you need to move an image as plain text through a system that only handles text fields.
In all of these cases, the same size trade-off applies — it's a convenience for moving or embedding data through text-only channels, not a technique for making images smaller or faster to transfer on their own merits.
Checking the size before you commit
Before embedding an image this way, it's worth actually looking at how much bigger the resulting string is compared to the original file — a converter that shows you the output length alongside the encoded string lets you make that call with real numbers instead of assuming it'll be fine. If the resulting string looks unreasonably long for what should be a small embedded graphic, that's usually a sign the source image itself is too large to be a good Base64 candidate in the first place.