Base64 vs Binary

What Is the Difference Between Base64 and Binary?

Base64 is a text representation of binary data using 64 ASCII characters (A-Z, a-z, 0-9, +, /). Binary is raw byte data stored and transmitted in its native format. Base64 adds 33% size overhead but enables embedding in text-based formats such as HTML, CSS, JSON, and XML.

Binary data consists of sequences of bytes (values 0-255) that represent file content in its most compact form. A 10 KB PNG file stored as binary occupies exactly 10,240 bytes. The same file encoded as Base64 occupies 13,656 bytes because every 3 bytes of binary input produce 4 bytes of Base64 output. This ratio is fixed: the overhead is always 33.33% plus up to 2 bytes of = padding.

The reason Base64 exists is that many transport protocols and document formats only support text characters. Email (SMTP), HTML attributes, CSS url() values, and JSON strings cannot contain raw binary bytes. Base64 solves this by encoding binary data into a safe subset of ASCII characters that passes through any text channel without corruption. For a detailed explanation of the encoding algorithm, see What is Base64.

How Do Base64 and Binary Compare for Web Performance?

Base64 inline embedding and binary file serving differ across 7 performance dimensions. The tradeoffs depend on file size, visit frequency, HTTP protocol version, and whether the asset is shared across pages. The table below summarizes each factor.

For first-time visitors, Base64 inline images load faster when the image is small because the browser does not need to open a new connection or wait for a separate response. For repeat visitors, binary files win because the browser serves them from its local cache without any network request. The crossover point depends on the specific scenario, but the widely accepted threshold is 10 KB.

When Should You Use Base64 Instead of Binary?

Base64 encoding is the better choice when the file is small, used once, and the delivery context requires text-only content. The saved HTTP request outweighs the 33% size increase for files under 10 KB. The following use cases favor Base64 embedding.

Images under 10 KB: Small icons, UI elements, and logos encode to under 13.3 KB as Base64. The eliminated HTTP request (50-200 ms round-trip) more than compensates for the extra 3.3 KB. The Base64 Image Encoder converts images to embeddable strings.

CSS background images used on every page: A 2 KB icon used as a CSS background on all pages benefits from being embedded in the stylesheet. The stylesheet itself is cached, so the embedded image data is effectively cached with it.

Email HTML templates: Email clients block external image loading by default. Base64-embedded images display immediately without requiring the recipient to click "load images." This is one of the strongest use cases for Base64 embedding.

JSON API payloads: When an API must return image data alongside metadata in a single JSON response, Base64 encoding is the standard approach. The application/json content type cannot contain raw binary data.

Single-page application assets: Bundled SPAs can inline critical icons to ensure the UI renders completely on the first paint without waiting for additional asset requests.

Configuration files: Application configs in YAML, JSON, or XML that need to include small images or certificates use Base64 to keep everything in a single text file.

Use the Base64 Embed Code Generator to produce ready-to-use HTML and CSS snippets for any image you decide to embed.

When Should You Use Binary Instead of Base64?

Binary files are the better choice when the asset is large, reused across pages, or benefits from independent caching and CDN delivery. The following scenarios favor serving raw binary files over Base64 embedding.

Images over 10 KB: A 50 KB image becomes 66.5 KB as Base64. The 16.5 KB overhead is significant, and the image cannot be cached separately from the HTML. Serving it as an external file with a Cache-Control: max-age=31536000 header means repeat visitors load 0 bytes for that image.

Frequently reused assets: A logo that appears on 100 pages costs 100x the Base64 size if embedded in each page's HTML. As an external file, it downloads once and serves from cache for the remaining 99 page loads.

Photographs and large graphics: JPEG photos typically range from 50 KB to 5 MB. Base64 encoding a 1 MB photo produces 1.33 MB of text that bloats the HTML document and cannot be streamed or progressively rendered.

CDN-delivered assets: Binary files can be distributed across a global CDN, serving from the edge node closest to the user. Base64-embedded data travels as part of the HTML, which may be served from a single origin server.

Lazy-loaded content: Below-the-fold images should load on demand as the user scrolls. Base64 embedding forces all image data to download with the initial HTML payload, defeating the purpose of lazy loading.

Responsive images with srcset: The HTML srcset attribute serves different image sizes based on viewport width and device pixel ratio. Data URIs cannot be used effectively with srcset because each variant would need to be embedded separately, multiplying the HTML size.

To convert Base64 data back to binary files, use the Base64 to PNG Converter or the Base64 Image Decoder.

How Does Base64 Affect Page Load Time?

The page load impact of Base64 encoding depends on 3 variables: the original file size, the number of embedded assets, and whether the page is a first visit or repeat visit. Quantifying each variable makes the tradeoff concrete.

Single small icon: A 10 KB image becomes approximately 13.3 KB as Base64. This adds 3.3 KB to the HTML but saves 1 HTTP request. On an HTTP/1.1 connection, each request adds 50-200 ms of round-trip latency depending on server distance. The 3.3 KB transmits in under 5 ms on any broadband connection. Net savings: 45-195 ms on first visit.

50 inline icons: If each icon averages 5 KB, the total binary size is 250 KB. As Base64, this becomes approximately 333 KB, adding 83 KB to the HTML. Under HTTP/1.1 with 6 parallel connections, loading 50 external files requires roughly 9 rounds of requests. Under HTTP/2, all 50 requests multiplex over 1 connection and may complete in 1-2 round trips. The break-even depends on the protocol version.

Repeat visits: On repeat visits, external binary files serve from the browser cache (0 ms, 0 bytes). Base64-embedded data re-downloads with the HTML every time the page is requested, unless the HTML itself is cached. For pages with short cache TTLs or dynamic content, binary files provide a significant advantage on repeat visits.

Use the Base64 Size Calculator to compute the exact size overhead for your specific files before deciding on an embedding strategy.

How Does HTTP/2 Change the Base64 vs Binary Decision?

HTTP/2 multiplexes multiple requests over a single TCP connection, reducing the latency cost of loading many small files. Under HTTP/1.1, browsers open 6 parallel connections and queue additional requests, creating significant overhead for pages with many assets. HTTP/2 eliminates this queuing.

Under HTTP/1.1, the primary argument for Base64 was reducing HTTP requests. Each request required a full TCP round-trip, and browsers limited parallel connections to 6 per domain. Loading 30 small icons required 5 rounds of 6 requests each. Base64 embedding collapsed all 30 requests into 0.

HTTP/2 changes this calculus. All 30 requests multiplex over 1 connection and can be initiated simultaneously. The overhead per request drops from a full round-trip to a small frame header (9 bytes). This makes binary files more competitive for medium-sized assets in the 5-20 KB range that would have been inlined as Base64 under HTTP/1.1.

The updated recommendation for HTTP/2 environments: embed only assets under 5 KB as Base64. Assets between 5-20 KB should be served as binary files to benefit from caching and compression. Assets under 2 KB remain strong candidates for Base64 embedding regardless of protocol version because the frame overhead of a separate HTTP/2 request approaches the size of the asset itself.

HTTP/3 (QUIC) further reduces per-request overhead by eliminating TCP head-of-line blocking. As HTTP/3 adoption increases, the threshold for Base64 embedding shifts even lower, favoring binary files for all but the smallest assets.

What Are the Caching Implications of Base64 vs Binary?

Browser caching is the largest long-term performance difference between Base64 and binary. Binary files can be cached independently with long TTLs (time-to-live). Base64 data embedded in HTML must be re-downloaded whenever the page changes. For assets used across multiple pages, binary is significantly more efficient.

Binary file caching: An image served with Cache-Control: max-age=31536000 (1 year) downloads once and serves from disk cache on all subsequent visits. If the image appears on 50 pages, the browser loads it from cache for 49 of those page views. The total bandwidth for that image across 50 pages is equal to 1 download.

Base64 caching: A Base64-encoded image embedded in HTML downloads with every page load. If embedded in CSS, it downloads once (when the CSS file loads) and serves from CSS cache on subsequent pages. Embedding in CSS is therefore more cache-friendly than embedding in HTML, provided the CSS file has a long cache TTL.

Cache invalidation: When you update a binary image file, you change its URL (using a hash or version parameter) and the browser fetches the new version. All other cached assets remain valid. When you update a Base64-embedded image, the entire HTML or CSS file that contains it must be re-downloaded, invalidating any other cached content within that file.

Service worker caching: Progressive web apps using service workers can cache binary files individually in the Cache API. Base64 data embedded in HTML cannot be cached separately through a service worker. For offline-capable applications, binary files provide more granular cache control.

For validating Base64 strings before embedding, use the Base64 Validator. To explore all available encoding and decoding tools, visit the BASE64IMAGE home page.

Frequently Asked Questions