A base64 data URI is usually fine for small assets like icons, but it gets too big when it starts hurting browser compatibility, HTML size, or page performance. In practice, keep it well under a few tens of kilobytes for broad compatibility, and avoid using it for large images or files.

Practical limits

  • Older Internet Explorer had a hard ceiling around 32,768 characters for data URIs, with IE8 especially restrictive.
  • Base64 expands data by about 33%, so a file that seems “small” can become much larger once encoded.
  • Some browsers historically accepted data URIs around 65,000 characters, while others were much more lenient, so there has never been a single universal safe limit.
  • For performance, large base64 URLs are generally discouraged even when they technically work, because they bloat HTML/CSS and can slow rendering.

Rule of thumb

  • Use base64 data URIs for tiny assets, such as icons or very small decorative images.
  • Avoid them for photos, large illustrations, or anything reused across pages.
  • If you need a rough cutoff, staying below about 20–25 KB of original binary data is a conservative choice for legacy-browser safety, because encoding overhead pushes the URI size up quickly.

Simple sizing example

A binary file grows by roughly one-third when base64 encoded, so 16 KB of raw data becomes about 21.3 KB in base64 text.

That means a “small” image can cross browser or sanitizer limits faster than expected, especially once you add the data:image/...;base64, prefix.

Best practice

If the asset is more than a tiny icon, store it as a separate file and let the browser fetch it normally. That is usually more reliable, easier to cache, and better for page speed.

TL;DR: for base64 URIs, “too big” is anything beyond small inline assets; keep them tiny, and treat roughly 20–25 KB raw as a conservative upper bound if you care about broad compatibility.