Why Large Files Don't Work Well with Base64?
And When Should You Use It?

Why Base64 Makes Files Larger

The core idea behind Base64 is: take 3 bytes (24 bits) of raw data at a time, split them into four 6-bit groups, and represent each group with one of 64 printable ASCII characters (A–Z, a–z, 0–9, +, /).

The result: 3 bytes become 4 characters. Each character takes 1 byte, so the size grows to 4/3 ≈ 133% of the original.

If the original data length is not a multiple of 3, = padding is added to make it a multiple of 4, so the actual increase is slightly more than 33%.

For example: a 5 MB image becomes about 6.7 MB in Base64; a 100 MB video becomes about 133 MB — 33 MB more than the original.

Why Browsers Freeze When Converting Large Files

The most common approach is FileReader.readAsDataURL(file). The problem lies in how this API works:

1. 1
   Reads the entire file into memory:The whole file is loaded into an ArrayBuffer at once. A 50 MB file occupies 50 MB of memory immediately.
2. 2
   Encodes on the main thread:Base64 encoding runs on the JavaScript main thread. During this time, the browser cannot respond to user interaction — the page freezes.
3. 3
   Builds a massive string:The result is an enormous string (a 50 MB file produces ~67 MB of Base64). JavaScript strings are immutable, so constructing one involves heavy memory allocation and copying.
4. 4
   Peak memory doubles:The original ArrayBuffer and the Base64 string both exist in memory at the same time, so peak usage is about 2.3x the file size. A 50 MB file can instantly consume ~115 MB of memory.

Three Approaches: Which One Should You Use?

Different scenarios have different optimal solutions. Here are typical use cases for each of the three file handling approaches:

File Size Reference Boundaries

There are no hard rules, but these boundaries are followed by most developers:

Handling Large-File Base64 with a Web Worker

If you really need to Base64-encode a large file in the browser, offloading the work to a Worker prevents UI freezes:

self.onmessage = function(e) {
  const buffer = e.data            // ArrayBuffer (zero-copy transfer)
  const bytes  = new Uint8Array(buffer)
  let binary   = ''
  const CHUNK  = 8192
  for (let i = 0; i < bytes.length; i += CHUNK) {
    binary += String.fromCharCode(...bytes.subarray(i, i + CHUNK))
  }
  const base64 = btoa(binary)
  self.postMessage(base64)
}

const worker = new Worker('/base64.worker.js')

input.addEventListener('change', async (e) => {
  const file   = e.target.files[0]
  const buffer = await file.arrayBuffer()

  // Transferable: buffer ownership transferred to Worker (zero-copy)
  worker.postMessage(buffer, [buffer])
})

worker.onmessage = (e) => {
  const base64 = e.data             // encoded result
  console.log('data:...;base64,' + base64)
}

The second argument to postMessage(buffer, [buffer]) is the Transferable list. The ArrayBuffer ownership is transferred zero-copy to the Worker, and the main thread's buffer becomes empty (byteLength 0), avoiding doubled memory usage.

Quick Decision: One-line Guide

Related Tools