Browser Crashes During Upload? Fixes for Stable Transfers

If your browser crashes mid-upload, the cause is almost always memory pressure on the tab. Chrome kills tabs that exceed roughly 2 to 4 GB of private memory, and a transfer service that loads a 10 GB file into a single Blob object will blow past that ceiling. Fix: use a service that streams the file in chunks via the File API's slice() method (most modern ones do), close every other tab before uploading, disable extensions that hook into fetch/XHR, and upload on a desktop rather than a laptop on battery power. Firefox typically handles large File API streams with less memory overhead than Chromium.

Why browsers crash on uploads

Two architectural realities collide. First, every browser tab is a separate process with its own memory ceiling. Chrome caps each renderer process at about 4 GB on 64-bit systems before the OOM killer steps in. Second, the naive way to upload a file in JavaScript is to pass the entire File object into a fetch body, which browsers often try to buffer in memory before sending.

A well-built transfer service never does this. It reads the file with File.slice(start, end) to produce a Blob for each 5 to 20 MB chunk, uploads that chunk, then releases it. Memory stays bounded at roughly chunkSize * concurrency bytes regardless of file size.

If your upload starts fine at 500 MB of progress and the tab goes grey at 2 GB, the service is loading the whole thing before sending. Pick a different service or a different approach.

Close other tabs aggressively

Chrome shares a single renderer process for some grouped tabs (Site Isolation changes this, but memory pressure is still shared at the system level). A second tab playing YouTube in 4K, a third with Figma loaded, a fourth with Notion consuming 800 MB of RAM each, all add up. A 10 GB upload on a laptop with 8 GB of RAM and 12 tabs open is playing with fire.

Before starting a big upload, quit Chrome entirely and reopen with just the transfer service's tab. Activity Monitor (macOS) or Task Manager (Windows) should show the browser using well under 2 GB on that single tab.

Disable extensions

Ad blockers, privacy extensions, password managers, and network analysers (uBlock Origin, Privacy Badger, LastPass, HTTP Toolkit) all inject into network requests. Most don't cause issues. Some, especially ones with outdated code, buffer request bodies to inspect them, which defeats streaming uploads and blows memory.

Test in an incognito window (extensions are disabled by default). If the upload completes cleanly in incognito, extensions are the issue. Enable them one at a time to find the culprit.

Disable hardware acceleration when the GPU is weak

Older laptops with integrated Intel UHD 620 or similar GPUs sometimes crash rendering a progress bar update plus the file read buffer simultaneously. Chrome's Settings > System > "Use hardware acceleration when available" can be toggled off. This loses some smoothness for everything else but stabilises large uploads on memory-constrained systems.

Similarly, disable Chrome's "Memory Saver" mode for the upload tab, which has been known to evict tabs under pressure mid-upload. Pin the tab or explicitly exclude it.

Switch to Firefox for very large files

Firefox historically handles the File API with tighter memory budgets than Chromium. On a 10 GB upload that crashes Chrome repeatedly, Firefox often completes the same job without drama. The difference isn't huge on well-built services (both handle chunked streaming fine), but on services with less-than-ideal implementations, Firefox's conservative memory model is more forgiving.

Safari on macOS is also reliable for large uploads, with the caveat that iOS Safari aggressively terminates background tabs.

Pin and foreground the tab

Background tabs are the first to be evicted under memory pressure. Keep the upload tab in the foreground. Don't switch to another window for 30 minutes and come back to find the tab reloaded. Chrome's "discarded" tabs show a grey placeholder on return, and any upload in progress is dead.

Cafeinate on macOS (caffeinate -s) or disable Windows' power-saving sleep during the upload. A sleeping laptop closes WebSocket and XHR connections, and not every service can resume cleanly afterwards.

Upload from desktop, not laptop on battery

Laptops on battery power throttle CPU and RAM aggressively. macOS's "Low Power Mode" and Windows' "Battery Saver" both reduce background task priority, which for a browser tab doing AES encryption and network writes means stalls.

Plug in. Disable battery-saver modes. If the laptop has a choice of CPU performance profiles (Dell Power Manager, Lenovo Vantage), set to "Performance" for the duration.

Restart the browser before starting

Chrome, Firefox, and Edge all leak memory slowly over long sessions. A browser that's been open for two days with 40 tabs opened and closed may carry 2 GB of zombie memory before you even open the upload page. Quit fully (Cmd+Q, not just closing the window, on macOS; right-click taskbar > Quit on Windows) and reopen.

Match chunk size to hardware

For services that let you configure chunk size (most don't, but some CLI tools like rclone do), smaller chunks use less memory. 5 MB chunks with 4 concurrent workers is 20 MB of buffer at any time. 100 MB chunks with 4 workers is 400 MB. On a 4 GB machine, the difference matters.

Web-based services pick defaults for you, typically in the 5 to 20 MB range per chunk, which is sensible. But custom scripts sometimes default to larger chunks to "go faster," and they fail on small machines.

Check RAM with Activity Monitor while uploading

During the upload, watch the browser process's memory. macOS Activity Monitor: Memory tab, filter by browser name. Windows Task Manager: Details tab, sort by "Memory (private working set)."

A healthy chunked upload holds steady at a few hundred MB of browser memory regardless of progress. If memory climbs linearly with upload progress (reaching 5 GB at 50 percent of a 10 GB file), the service is buffering everything. That's the bug. Find a different service.

Use services built for large browser uploads

A well-engineered transfer service uses chunked uploads with a Web Worker pool for encryption, bounded memory, and explicit retry on failed chunks. HexaTransfer reads files via File.slice() in Web Workers, encrypts with AES-256-GCM per chunk, and never exceeds a few hundred MB of browser memory regardless of whether you're sending 50 MB or the full 10 GB per-transfer ceiling, which matters when your browser is already dealing with everything else your day is throwing at it.

Try it at hexatransfer.com — free, no account, 10 GB max.