Base64 Data URI Overhead Calculator
Calculate byte size inflation, Data URI header overhead, gzip transfer size, and latency trade-offs when inlining images into HTML or CSS.
Raw Asset Size & Media Format
How Base64 Encoding & Data URI Overhead Work
The data: URL scheme (RFC 2397) allows small media assets like icons, logos, and fonts to be directly embedded inline into HTML or CSS stylesheets as Base64 strings.
The ~33% Size Expansion Formula
Base64 converts binary data into ASCII characters using a 64-character alphabet. Because each character represents 6 bits of data, 3 bytes (24 bits) of raw binary input produce 4 characters (32 bits) of Base64 output:
- Base64 Payload:
Base64_Bytes = 4 × ceil(Raw_Bytes / 3) - Data URI Header: The prefix
data:<mime>;base64,adds between 22 and 24 characters. - Total Data URI Size:
Total_Bytes = Base64_Bytes + Header_Bytes - Overhead Percentage:
Overhead % = ((Total_Bytes - Raw_Bytes) / Raw_Bytes) × 100%
When to Inline vs. Load Externally
- Inline (< 1.5 KB): Beneficial for tiny SVG icons and critical above-the-fold UI symbols to eliminate an extra HTTP/2 round-trip request.
- External File (> 1.5 KB): External images leverage browser HTTP caching across multiple pages, parse asynchronously off the HTML critical rendering path, and avoid the permanent 33% markup bandwidth penalty.
Frequently Asked Questions
Does Gzip compression eliminate the 33% Base64 overhead?
No. While Gzip compresses Base64 text by roughly 25%, already-compressed binary images (like PNG, WebP, JPEG) cannot be compressed further by Gzip. Therefore, a Base64-inlined image transferred over Gzip remains ~20-30% larger on the wire than serving the raw binary file directly.
Does inlining images hurt page load performance?
Inlining large images inflates HTML and CSS bundle sizes, which delays DOM parsing and First Contentful Paint (FCP). Inlined assets also cannot be independently cached by the browser cache.
What is the standard Data URI scheme header?
The standard syntax is data:[