Base64 vs Binary: When to Use Each

← Back to Blog

Base64 vs Binary: When to Use Each

· 5 min read

Advantages of Binary Transmission

The greatest advantage of directly transmitting raw binary data (without Base64 encoding) is efficiency: no 33% size overhead, no encoding/decoding computational cost, and the receiver can directly use the received bytes. In bandwidth-sensitive or latency-sensitive applications (like video streaming, real-time gaming, large file transfer), binary transmission is clearly the superior choice.

Modern web protocols already support binary data transmission well. WebSocket supports Binary Frames, HTTP/2 is itself a binary protocol, HTTP's multipart/form-data format allows direct binary file uploads, and gRPC uses Protocol Buffers for efficient binary serialization.

Where Base64 Is Appropriate

Despite binary being more efficient, Base64 remains necessary or more appropriate in these scenarios: the transport layer only supports text (like email SMTP's 7-bit ASCII restriction); data needs to be embedded in text-format documents (like JSON, XML, YAML, HTML); ensuring data isn't modified by various text processing systems (some systems modify specific byte sequences); data needs to be transmitted in URLs or HTTP headers.

A key judgment criterion: is your transport channel and storage system "binary-safe"? If yes (like modern database BLOB columns, S3 object storage, WebSocket binary frames), prefer binary. If uncertain or explicitly text-only, use Base64.

Choosing in JSON APIs

JSON is a text-based format that cannot directly contain binary data. When JSON APIs need to transmit binary content (like images, PDFs), there are several options: (1) Base64 strings: simplest, best compatibility, but 33% size increase; (2) Data URLs: similar to Base64, additionally includes MIME type information; (3) Separate upload: first upload the file via multipart/form-data, get a file URL, then reference that URL in JSON, keeping JSON compact.

Google's API design guide recommends: for small binary data (under 10KB), Base64 string inline in JSON is acceptable; for large binary data, use a separate media upload endpoint that returns a resource URI for subsequent reference. This guideline has been adopted by many well-known APIs (like Google Cloud Vision, Twilio).

Storing Binary Data in Databases

Major databases provide dedicated binary data types, generally more efficient than Base64 strings. PostgreSQL's BYTEA type stores raw binary directly, automatically displaying in hex escape format during queries. MySQL's BLOB family of types also stores binary directly without Base64 conversion. MongoDB's Binary type (BSON BinData) is also native binary storage.

Sometimes developers store Base64 strings in TEXT or VARCHAR columns instead of using BLOB/BYTEA. This is not recommended because: (1) 33% size increase; (2) lacks semantic information about binary data, making optimization difficult; (3) ORMs may not correctly handle comparisons and indexing. If using Base64 for readability or cross-database compatibility reasons, have sufficient justification.

WebSocket: Binary vs Text Frames

The WebSocket protocol supports two frame types: text frames (UTF-8 text) and binary frames (raw bytes). If your WebSocket application needs to transmit images or audio, use binary frames rather than Base64-encoding the data into text frames. Binary frames have no encoding overhead, and most WebSocket libraries handle binary frames well.

// 使用 WebSocket 二进制帧传输图片（浏览器）
// Using WebSocket binary frames to transmit images (browser)
const ws = new WebSocket('wss://example.com/ws');
ws.binaryType = 'arraybuffer'; // 或 'blob'

// 发送二进制数据 / Send binary data
const imageBuffer = await fetch('/image.png').then(r => r.arrayBuffer());
ws.send(imageBuffer); // 直接发送，无需 Base64

// 接收二进制数据 / Receive binary data
ws.onmessage = (event) => {
  if (event.data instanceof ArrayBuffer) {
    const blob = new Blob([event.data], { type: 'image/png' });
    const url = URL.createObjectURL(blob);
    document.querySelector('img').src = url;
  }
};

Protocol Buffers vs JSON+Base64 Comparison

Protocol Buffers (protobuf) is a binary serialization format developed by Google, with significant advantages over JSON+Base64: smaller size (typically 20–80% of JSON, far smaller than JSON+Base64); faster parsing (5–10x); strong typing reducing errors; built-in support for binary fields (bytes type).

In scenarios requiring high-performance binary data transmission (like microservice communication, high-frequency API calls), protobuf is typically a better choice than JSON+Base64. But if readability, debugging convenience, or interoperability with systems not supporting protobuf is more important, JSON+Base64 remains a reasonable choice.

Decision Framework Summary

A concise decision framework for choosing binary vs Base64: if the transport or storage layer only supports text, Base64 is required; if data needs to be embedded in JSON/XML/YAML, use Base64; if data volume is large (>10KB) and performance matters, prefer binary (multipart upload, BLOB storage, binary WebSocket frames); if data volume is small (<10KB) and convenience is prioritized, Base64 is an acceptable choice.

Try the online tool now — no installation, completely free.

Open Tool →