When to Use Base64 (and When to Just Send the File)

Base64 encoding is everywhere. Sometimes it's the right tool. Often it's not. Knowing when to use it (and when to skip it for direct file transfer) saves you bandwidth, complexity, and confusion. Here's the practical guide.

Use Base64 when:

1. You need to embed binary in text-only formats

Email body (RFC 822), JSON, HTML, XML — these are text formats that don't tolerate raw binary bytes. To put binary content in them, you must encode.

Examples:

• Email attachment in MIME
• Image in an SVG or HTML data URI
• Binary blob in a JSON API response
• Certificate in a configuration file

2. You're embedding small assets in HTML/CSS

Small icons (under 5 KB) embedded as data URIs save a network request:

background-image: url('data:image/png;base64,iVBORw0KGgo...');

The browser doesn't have to make another HTTP request. For mobile apps and high-latency connections, this matters.

Threshold: typically 5–10 KB. Above that, the embed is too big and you should use a separate file.

3. You need cryptographic notation

Public keys, certificates, signatures, and JWTs are conventionally Base64-encoded. Examples:

• RSA/ECDSA public keys in PEM format ("-----BEGIN PUBLIC KEY-----")
• X.509 certificates
• JSON Web Tokens (JWTs) — three Base64URL parts
• OAuth state parameters

These are conventions, not requirements. But following them makes interop with libraries easier.

4. You need URL-safe data transit

Base64URL (the URL-safe variant) is good for state parameters in URLs, query strings, and OAuth flows.

Example: encoded redirect URL after login. The destination URL (which might contain special characters) is Base64URL'd into a single safe parameter.

5. You're working with QR codes or short-distance transit

Some QR code libraries prefer text input. Base64-encoding small binary blobs lets them go through.

For PIN-to-PIN messaging (e.g., Bluetooth Low Energy notifications), Base64 keeps payloads in the text format the protocol expects.

Skip Base64 when:

1. The file is large

33% overhead is meaningful at scale. A 100 MB file becomes 133 MB Base64. For:

• Photo uploads from mobile
• Video uploads
• Database backups
• ML model files

Send the file as binary using multipart/form-data, signed S3 URLs, or a dedicated file upload endpoint.

2. You'd be encoding a compressed file

If your data is already compressed (ZIP, GZIP, encrypted), Base64-encoding it adds 33% overhead with no benefit. Both compression and Base64 want to use up the bits — Base64 wastes them.

Send compressed data as binary directly when possible.

3. The receiver expects binary

If you're sending data to a system that natively handles binary (S3 bucket, Redis with binary values, MongoDB binary type), don't add Base64. Send raw bytes.

4. You think Base64 is encryption

It's not. Base64 is just a different way of encoding the same data. Anyone can decode it instantly with a standard library.

If you need security, use actual encryption (AES, ChaCha20). Base64 ≠ secure.

5. You can use a separate file URL

Hosting an image at /images/logo.png and including the URL in JSON is almost always better than including a Base64-encoded image in the JSON. The URL is small (~50 chars), cacheable across requests, and lets browsers/clients fetch it lazily.

Exception: when network requests have high overhead (cellular, satellite, mobile-restricted), embedding small items as Base64 saves round trips.

Common Base64 mistakes

1. Using Base64 instead of binary uploads. Many APIs accept JSON-only payloads, forcing developers to Base64-encode large files. This is bad design — use multipart/form-data or pre-signed URL uploads instead.

2. Confusing Base64 and Base64URL. "+/" vs "-_" — using the wrong variant in a URL context fails.

3. Stripping or adding padding incorrectly. Some decoders require padding; others tolerate or require its absence. Be explicit.

4. Using Base64 for "obfuscation". Base64-encoded API keys are no more secure than plaintext keys. Don't kid yourself.

5. Embedding huge images in HTML. A 500 KB Base64'd image in HTML inflates the page to 665+ KB and prevents browser caching of the image separately. Bad performance pattern.

Base64 vs alternatives

Base64 vs Hex: Hex is 2 chars per byte (100% overhead). Base64 is 4 chars per 3 bytes (33% overhead). Base64 wins on size; hex wins on simplicity.

Base64 vs Base85: Base85 is ~25% overhead vs Base64's 33%. Slightly more efficient but rarely used outside Adobe PDF.

Base64 vs URL-encoded binary: URL encoding (%XX) inflates by ~3× for binary data. Base64 is much more efficient.

Real-world performance

Encoding/decoding speed is rarely the bottleneck. Modern CPUs do gigabytes/sec of Base64. The size overhead matters more for bandwidth and storage costs.

For a high-volume API: 33% larger payloads = 33% more bandwidth = 33% more egress costs at AWS/GCP scale. For a single user, negligible.

Checking sizes

Our Base64 length calculator handles the size math. Useful for evaluating tradeoffs: "is this worth Base64-encoding?" Often the answer is "no — send it as a separate file or URL."