Base64 Image Not Showing? Tested Causes and Fixes

By Syed Arbaz Ali Rizvi, founder of BeeToolify. Published 26 October 2026.

Short answer: a base64 image fails to show for only three reasons in our testing: the src is missing the data: prefix, it is missing the ;base64 marker before the payload, or the prefix got pasted twice. We rendered 11 common data URL variations in a browser and 8 of them loaded, including ones with line breaks, extra whitespace, removed padding, and even the wrong MIME type. The fixes people often recommend for newlines and padding are solving problems the browser already handles. Build the prefix exactly, and use the Base64 Encoder to verify your string round-trips.

What actually breaks a base64 image

The browser's data URL parser cares about the structure of the prefix far more than the cleanliness of the payload. When an image shows a broken icon or nothing at all, it is almost always because the src does not parse as a valid data URL in the first place. Three failures cover nearly every case we could reproduce:

• Missing the data: prefix. If you paste the base64 characters straight into a src with no data: scheme, the browser treats the value as a relative file path, finds no such file, and shows a broken image. This is the single most common cause, and it comes from copying just the payload out of an encoder while leaving the prefix behind.
• Missing the ;base64 marker. Without this marker, the browser assumes the characters after the comma are literal URL-encoded text, not a base64 payload, and the decode produces garbage that will not render. The marker must sit between the MIME type and the comma.
• The prefix pasted twice. A double paste yields data:image/png;base64,data:image/png;base64,.... The second embedded prefix is not valid base64, so the decode fails and the image breaks. This usually happens when a prefix is prepended to a value that already carried one.

Why the common fixes are usually unnecessary

Search for this problem and the top advice is to strip line breaks and restore the trailing = padding. Those are reasonable hygiene steps, but our tests show they are almost never the reason an image fails in a browser. We took a working data URL and deliberately broke it in the ways people worry about: injecting a line break every 20 characters, removing all the padding, and adding stray whitespace. Every one of those still rendered.

The browser's base64 decoder skips ASCII whitespace and re-pads short strings to a valid length on its own. So while cleaning the payload is harmless and can help stricter non-browser decoders, it will not rescue an image that is broken because of a prefix problem. Fix the prefix first.

Why does the wrong MIME type still load?

We declared image/jpeg while feeding the encoder PNG bytes, and the image rendered correctly. Browsers sniff the actual format from the payload rather than trusting the declared MIME type for local rendering. That is why a mismatched MIME type is not a reliable cause of a blank image in the browser, though other consumers of the same string (a server-side parser, a strict native app) may be less forgiving.

The takeaway: if the image fails, do not start by auditing the MIME string. Confirm the data: scheme and the ;base64 marker are both present and in the right order, then look for a doubled prefix.

Why does it work in an img but break in CSS?

This is the one context difference that does catch people out, and it is about quoting, not base64. In HTML the value lives inside an attribute surrounded by quotes. In CSS it lives inside a url() function in a stylesheet, where a stray quote, an unescaped parenthesis, or a missing semicolon can end the value early and leave the rest as garbage. If your image renders as an HTML img but not as a CSS background, inspect the stylesheet for a quoting problem around the url() value before suspecting the base64 string itself.

How big can a data URL get?

There is no fixed limit in the specification, and browsers handle large data URLs in an img src without complaint. The practical cost is size: base64 encoding inflates a payload by about a third, because every three bytes of binary become four text characters. A 1 MB image becomes roughly 1.33 MB of text in your markup. For an image a handful of people see, inlining is fine. For an image shipped to thousands of page views, that inflation is why most teams keep images as normal files and reference them by URL instead.

How do I fix it for good?

1. Inspect the prefix. Open the src and confirm it reads data:, then a MIME type, then ;base64,, then the payload, with each part in order and the scheme appearing exactly once.
2. Remove any doubled prefix. If you see data: twice, keep only the leading one and the comma that follows it.
3. Regenerate to verify. Paste your payload into the Base64 Encoder, encode it, and confirm the output round-trips to the original. If it does, the string itself is sound and the fault is in how it is embedded.

What did we actually test?

We built 11 variations of a base64 image data URL in headless Chrome on a Windows machine (2026-10-26) and loaded each one as an image src, recording whether it loaded, threw an error, or did neither. The cases included a correct data URL, a missing MIME type, raw base64 with no data: prefix, a wrong MIME type, a missing ;base64 marker, injected newlines, stripped newlines, removed padding, removed padding plus trailing whitespace, a doubled prefix, and unconverted base64url characters. The three breakers listed above were the only ones that produced an error; the rest loaded.

What this test does not cover: it uses one browser engine (Chromium). Firefox and Safari may differ on edge cases such as very large data URLs or unusual whitespace handling, and it does not test non-browser consumers like strict parsers, email clients, or native apps, which can be less tolerant than a browser. The prefix-structure findings follow from how the data URL format is defined and hold broadly, but always verify in the target environment if you are shipping outside a browser.

Quick FAQ

Why is my base64 image showing a broken icon?

In our testing only three things break a data URL image: the value is missing the data: prefix so the browser does not recognize it as a data URL, it is missing the ;base64 marker before the payload, or the prefix was pasted twice. Any of those three makes the browser show a broken image. Fix the prefix structure and the image loads.

Do I need to remove newlines from base64 for it to work in an image?

No, not in our tests. We injected a line break every 20 characters into a working data URL and the browser still rendered it. Line breaks matter in some non-browser contexts such as strict parsers, but an img src in a browser tolerates them. Stripping whitespace is a safe cleanup, not a required fix.

Does missing base64 padding break the image?

Not in our tests. We removed the trailing equals signs from a valid data URL and the image still loaded, because browsers pad the string back to a valid length themselves. Restoring padding is good hygiene for other decoders, but it was not what caused a blank image in any of our cases.

Can a wrong MIME type stop a base64 image from showing?

We declared image/jpeg while feeding it PNG bytes and the browser still rendered the image, because it sniffs the actual format. A wrong MIME type is therefore not a reliable cause of a broken image in browsers, though other consumers of the same string may be stricter. The two reliable breakers are a missing data: prefix and a missing ;base64 marker.

Why does my base64 image work in an HTML img but not in CSS?

The main difference is quoting and encoding, not the base64 itself. In HTML the value sits in an attribute surrounded by quotes, while in CSS url() it sits inside a stylesheet where a stray quote, parenthesis or semicolon can terminate the value early. If it renders in an img but not in CSS, check that the url() value is quoted correctly and that the payload contains no characters that close the statement.

How big can a base64 data URL be before browsers refuse it?

There is no fixed number in the specification, and browsers handle large data URLs well in img src, but base64 encoding inflates the payload by about a third, so a 1 MB image becomes roughly 1.33 MB of text. Very large data URLs increase page weight and can slow parsing, which is why images shipped to many users are usually kept as normal files rather than inlined.

Encoding a lot of text or files and need a reliable string back? Our Base64 Encoder handles UTF-8 correctly and shows the decoded round-trip, and if you also need to verify a file arrived intact, the Hash Generator computes its SHA-256 in the same browser session.