Base64 - When to Use and When Not To

Last reviewed 2026-04-27. Open Base64 to Image or Image to Base64 for in-browser conversion.

Free Tool Online Editorial Team

What base64 actually does

Take three bytes of binary input - 24 bits. Group them as four 6-bit chunks. Map each 6-bit chunk to one of 64 ASCII characters (A-Z, a-z, 0-9, +, /). Output is now safe to put in an email body, a URL, a JSON string, or a JavaScript source file - none of which handle raw binary cleanly.

The price is the encoding's expansion: every 3 bytes in becomes 4 bytes out. Plus padding (the "=" signs at the end) for inputs whose length is not a multiple of 3. The math is exact: encoded size = ⌈input/3⌉ × 4 bytes.

Right call: small inline binary in text protocols

• Small inline images. A 1 KB icon in a data URL inside CSS avoids a separate HTTP request. The 33% bloat costs 300 bytes; the saved request costs at least 1 RTT plus headers. Below ~4 KB, inline wins. Above that, a separate file with HTTP/2 multiplexing is faster.
• Email attachments. SMTP and email bodies are 7-bit ASCII by tradition. MIME wraps binary attachments in base64 specifically to fit the protocol. You almost never see this directly - mail clients encode and decode automatically.
• Binary in JSON. JSON only stores strings, numbers, booleans, arrays, and objects. To put binary in a JSON field, you base64 it. APIs that return image bytes inside JSON, OAuth tokens with binary signatures, and protobuf-over-JSON all use this pattern.
• URL parameters with binary. URL-safe base64 (using - and _ instead of + and /) lets you put short binary identifiers in query strings without percent-encoding.

Wrong call: large payloads or fake encryption

• Embedding large images in CSS or HTML. A 500 KB photo as a data URL becomes 670 KB of base64 plus the parser overhead, plus it cannot be cached separately, plus it blocks the parser. Just link the image file.
• "Encoding" sensitive data. Base64 is reversible by anyone. It is encoding, not encryption. Putting a password or API key through base64 obfuscates nothing - the decode is one click.
• Storing files in a database. Most databases have native binary types (BLOB, BYTEA). Storing binary as base64 in a TEXT column wastes 33% of the disk and forces a decode on every read.
• Long-running data transfer. If the binary is multi-megabyte, every byte of overhead matters. Stream the binary directly with the right Content-Type header.

Tools and decision rules

Convert in the browser - Image to Base64 for outgoing, Base64 to Image for incoming. Both work without uploading the file.

The simple decision rule: under 4 KB and inline-friendly destination → base64 is fine. Over that or anywhere with a real binary path available → use the binary path. The full developer set is at the developer tools hub.

About the 4 KB threshold

The 4 KB rule of thumb is an HTTP/1.1-era heuristic for inline images in CSS data URLs - on HTTP/1.1 each separate request paid roughly 1 RTT plus header overhead, so under 4 KB an inline image was cheaper than a second request even with the base64 33 percent expansion. On HTTP/2 and HTTP/3 the request cost falls (header compression, multiplexing on one connection), and the break-even point shifts up: a separate file is faster sooner. The decision rule still holds in shape - small inline binary in a text destination is the right call; large binary that has a real binary path is the wrong call - only the exact threshold moves with the underlying protocol.