Base64 Limits: Stream Chunks vs. Blocking 500MB Uploads

You're Not Hitting a Bug. You're Hitting a Wall.

Most frontend developers assume that if FileReader.readAsDataURL() returns a string, it worked. The tab didn't crash. The network request fired. Ship it. Then a QA engineer uploads a 180 MB PDF from their desktop, the browser tab freezes for forty seconds, and Chrome's "Aw, Snap" screen replaces the entire session. The instinct is to blame the framework, the upload component, or a memory leak in the SPA. It's none of those. The browser simply ran out of memory converting the file to a Base64 string, and nobody on the team had calculated the actual cost.

This is a pitfalls guide for developers building file-to-Base64 workflows in the browser. Not server-side encoding. Not Node streams. The specific, unforgiving environment of a browser tab with a hard memory ceiling and a single-threaded event loop.

Mistake #1: Assuming the File Size Equals the Memory Cost

Here's the math most teams never run before shipping a Base64 upload feature.

Take a 100 MB file. Base64 encoding inflates binary data by roughly 33%, so the encoded string is about 133 MB. But JavaScript strings in browsers are stored as UTF-16, meaning each character occupies 2 bytes in memory. That 133 MB string now consumes approximately 266 MB of heap space. Add the original ArrayBuffer held by FileReader (another 100 MB), intermediate buffers during the read operation, and any existing application state. A single 100 MB file conversion can peak at 400+ MB of memory inside one tab.

The Real Threshold

Chrome's renderer process typically crashes around 2 GB on 64-bit systems, but performance degrades long before that. Garbage collection pauses become visible at around 500 MB of live objects. Safari on iOS is stricter, often terminating pages that exceed 1 GB. If your upload component converts anything over 50 MB to Base64 synchronously, you're already in the danger zone for mobile browsers.

Mistake #2: Using FileReader Without a Size Guard

The standard pattern looks innocent:

const reader = new FileReader();
reader.onload = () => sendToApi(reader.result);
reader.readAsDataURL(file);

This works perfectly for a 2 MB profile photo. It silently destroys the page for a 200 MB video export. There's no built-in throttle. FileReader reads the entire file into memory, encodes it to Base64 in one pass, and hands you the full string. The browser cannot stream this to disk or release the buffer mid-operation.

The Fix: Gate by File Size Before Reading

Step one of any browser-based Base64 conversion pipeline: check file.size before calling any read method. Set a hard ceiling based on your target environment. For cross-browser mobile support, 30 MB is a reasonable maximum for direct Base64 conversion. For desktop-only internal tools, 100 MB is pushing it. Beyond those limits, redirect to a chunked upload strategy or a direct-to-storage signed URL approach that never touches Base64.

Mistake #3: Holding the Encoded String in React/Vue State

Even if the conversion succeeds, storing the result in component state triggers a second problem. React's reconciliation, Vue's reactivity system, and Angular's change detection all iterate over reactive properties. A 266 MB string sitting in a useState hook means every render cycle touches that object. DevTools will hang. The profiler becomes unusable. The string isn't technically reprocessed, but the reference checks and dependency arrays that scan it are enough to stall the main thread.

The Fix: Treat Base64 Strings as Transient

Convert, send, discard. The encoded string should exist only inside the callback scope of the read operation. Pass it directly to your API client and let it fall out of scope immediately so the garbage collector can reclaim the memory. If you must display a preview, generate a separate, small thumbnail rather than binding the full Base64 string to an <img src> attribute.

Mistake #4: Ignoring the Encoding Tax on Network Transfer

Teams often choose Base64 because their API expects JSON payloads, and JSON can't carry raw binary. Fair enough. But they forget that the 33% size inflation applies to the network transfer too. A 100 MB file becomes a 133 MB HTTP request body. Most reverse proxies and API gateways have default body size limits: NGINX caps at 1 MB by default, AWS API Gateway at 10 MB, and Cloudflare at 100 MB on free plans. Your browser might survive the conversion, but the request never reaches your application server.

The Fix: Know Your Infrastructure Limits

Before implementing client-side Base64 encoding, trace the full path: browser memory limit, request body size limit on every proxy in the chain, and the server framework's payload parser limit (Express defaults to 100 KB via body-parser). The lowest number in that chain is your real ceiling. If it's lower than your expected file sizes, Base64 over JSON is the wrong architecture. Switch to multipart form uploads or presigned S3 URLs.

Mistake #5: Attempting Chunked Encoding Manually

When developers discover the memory problem, the next move is often a hand-rolled chunked encoder: read the file in slices using file.slice(start, end), encode each chunk to Base64, and concatenate the results. This is theoretically sound but practically treacherous.

The trap is in the concatenation. JavaScript strings are immutable. Each chunk1 + chunk2 operation creates a new string containing both, while the originals remain in memory until GC runs. Concatenating 100 chunks of 1 MB each produces a temporary memory footprint that dwarfs the final string. You end up using more memory than the naive single-pass approach.

The Fix: Use the Right Tool

If chunked conversion is genuinely necessary, push each encoded chunk into an array and use Blob construction to assemble the final output without string concatenation:

const chunks = [];
for (let i = 0; i < file.size; i += CHUNK_SIZE) {
  const slice = file.slice(i, i + CHUNK_SIZE);
  const buf = await slice.arrayBuffer();
  chunks.push(encodeChunkToBase64(buf));
}
const blob = new Blob(chunks, { type: 'text/plain' });

A Blob holds the data without decoding it into a single contiguous string, letting you stream it via fetch without the memory spike. This approach keeps peak memory proportional to chunk size rather than total file size.

When to Abandon Base64 Entirely

Here's the honest threshold table we use for browser-based file handling:

- Under 5 MB: Base64 in JSON is fine. No special handling needed. - 5 MB to 30 MB: Base64 works but add a loading indicator and size guard. Avoid storing the string in reactive state. - 30 MB to 100 MB: Only on desktop browsers with explicit user warnings. Use chunked Blob assembly. Test on Safari separately. - Over 100 MB: Do not use Base64 in the browser. Use presigned storage URLs and upload raw binary directly.

These numbers aren't theoretical. They're derived from testing file conversion across Chrome, Firefox, Safari, and Edge on both desktop and mobile devices, measuring peak memory via Chrome DevTools Memory profiler and Safari's Web Inspector. Every threshold has a safety margin built in, but every margin assumes you're not running other heavy operations simultaneously. If your SPA already consumes 200 MB at idle, subtract that from every number above.

The Bottom Line

Browser memory limits aren't a bug to fix. They're a physical constraint to design around. Base64 is convenient for small payloads, but the 33% size inflation, UTF-16 doubling, and string immutability compound into a memory footprint that's 4-5x the original file size. No amount of framework optimization changes that math. The fix is always the same: measure the file, know your ceiling, and pick the right transfer mechanism before the conversion ever starts.