Browsers can now process images, video, PDFs, and databases directly, but large files can still make an operation slow or cause it to fail because memory runs out. That naturally raises the question “how many gigabytes can a browser handle?”, yet the practical limit is not determined by file size alone.
A 10 GB file that can be read in small ranges may be easier to handle than a few-hundred-megabyte file that must be fully decoded while several intermediate copies coexist. The more useful question is not just how large the file is, but what happens inside the device while it is being processed.
Four factors that shape the practical limit
What must exist in memory at once
Memory may hold more than the source file: decoded pixels or frames, analysis arrays, WebAssembly memory, and output buffers can coexist.
How much computation is required
Simply inspecting a file can be much cheaper than compressing, converting, running AI, or re-encoding it.
How many copies and temporary buffers are created
Copies between JavaScript, workers, Wasm, decoders, and output buffers can push memory far beyond the source file size.
Browser and device headroom
The same web app can behave very differently on a phone and a powerful desktop because memory, CPU, APIs, and codecs differ. With large files, storage read speed and writing the final output can also become bottlenecks.
File size is not the same as required memory
Selecting a file does not necessarily copy every byte into JavaScript memory immediately. Browsers expose files as File / Blob objects, and applications can read the whole file into an ArrayBuffer, take byte ranges with slice(), or consume it progressively with stream(). A large file therefore does not always need to be loaded in full at the start.
If an app calls Blob.arrayBuffer() for the entire file, however, it needs memory for those bytes. Subsequent decoding, parsing, or intermediate results can require additional buffers, so a 500 MB file does not imply that 500 MB of free memory is enough.
Compressed files can expand dramatically while being processed
JPEG images, ZIP archives, common video files, and compressed Parquet data can occupy less space when stored than they require while being processed. Some operations need to expand that representation into a form that is easier to compute on, and the expanded data can be far larger than the file on disk.
Images are an easy example. With common 8-bit RGBA ImageData, each pixel is represented by four values. An 8000 × 6000 image therefore needs about 192 million bytes for that pixel array alone. A JPEG that occupies only tens of megabytes on disk can still involve roughly 192 MB of pixel data during editing or analysis, and multiple source or destination canvases can multiply that amount.
Copies and temporary buffers create hidden memory pressure
During processing, the same content may exist in several places: an ArrayBuffer read from the file, a worker input, WebAssembly memory, a decoded or transformed buffer, and finally a Blob prepared for download. Not every implementation copies data in exactly this way, but temporary generations can overlap and increase peak memory substantially.
When passing an ArrayBuffer to a Web Worker, an application can transfer ownership instead of cloning the underlying memory. For large datasets, avoiding unnecessary copies can materially increase the size of file an application can handle reliably.
Moving work to a Worker does not make the work disappear
Web Workers can run expensive JavaScript away from the main thread that handles the interface. That helps buttons, progress indicators, and scrolling remain responsive while a large file is being analyzed, which is important for user experience.
The computation itself still has to happen. If video encoding requires a certain amount of CPU work, moving it to a worker does not erase that work. Parallel algorithms may use multiple cores and finish sooner, but worker-based execution and low computational cost are not the same thing.
WebAssembly engines have their own linear memory too
When an existing engine such as FFmpeg or DuckDB runs as WebAssembly, it uses WebAssembly.Memory, a linear memory region. Depending on the implementation, that memory may grow as the engine needs space for inputs, working data, and results.
That memory is only one part of the page’s total footprint. JavaScript ArrayBuffers, canvases, browser decoder buffers, DOM state, and output Blobs may also consume memory on the same device. Looking only at the Wasm memory size therefore does not reveal the full peak working set.
Large-file-friendly tools often avoid reading everything
When the format and operation allow it, an application does not need the whole file in memory. File / Blob data can be sliced into ranges or read as a stream. A viewer can load only the current page, a log parser can scan line by line, and a columnar reader can fetch only the relevant blocks or columns.
That architectural difference is significant. Even a 1 GB file can be easier on memory when only a few megabytes or tens of megabytes are processed at a time. Conversely, a few-hundred-megabyte source can be demanding if the application expands the entire file and keeps source, intermediates, and output simultaneously. Not every format or operation can be processed incrementally, however; some require random access or whole-file context.
Different kinds of large files hit different bottlenecks
The phrase “large file” does not identify the bottleneck by itself. Images, video, PDFs, and databases stress different parts of the browser and device.
In particular, being able to open a file is different from being able to transform it. Reading metadata or a small set of records may be cheap, while decoding an entire image, re-encoding every video frame, or sorting a full dataset can put much more pressure on CPU and memory.
| Target | Common expensive work | Practical point |
|---|---|---|
| Images | Decoding high-resolution pixels, multiple canvases, filters, re-encoding | Pixel dimensions can matter more than compressed file size |
| Video & audio | Decode, encode, frame processing, audio processing, remuxing | Resolution, duration, codec, and operation matter alongside file size |
| PDFs & archives | Page rasterization, embedded images, decompression, holding many extracted files | Page count is not enough; embedded image size and expanded size also matter |
| Data & databases | Parsing, decompression, SQL, sorting, aggregation, intermediate tables | Selective reads and queries can avoid paying for the entire file at once |
So how many gigabytes can a browser handle?
There is no universal “up to N GB” value that applies to every browser, device, format, and operation. The practical ceiling depends on physical memory, other tabs and applications, browser implementation details, the execution environment, WebAssembly or decoder behavior, and the algorithm used by the application.
When a tool documents a limit such as 2 GB, that may describe the tool’s own implementation or tested range rather than a universal browser specification. For large files, it is more useful to ask whether the tool loads everything at once, can work in chunks, supports cancellation, shows progress, and is designed for the device you plan to use.
Browser Kitty does not treat local processing as unlimited
Browser Kitty prefers on-device processing when user files do not need to be sent elsewhere. That also means the user’s CPU and memory replace server resources. Fully local processing and unlimited large-file capacity are not the same thing.
Some viewers can reduce memory pressure by reading only the current page or relevant blocks, while tasks such as video compression must decode and re-encode media and are much more sensitive to device performance. Good browser-local design therefore includes not only privacy boundaries but also memory use, cancellation, progress, and clear failure states.
Four things to check before processing a large file
File size alone is a weak predictor. These four checks give a better idea of whether the task is practical in the browser.
- Look at what the file containsFor images, check pixel dimensions; for video, resolution, duration, and codec; for PDFs, page count and embedded images; for data, rows, columns, and compression. File size alone does not describe the workload.
- Look at the operationDistinguish inspection from re-encoding, compression, AI analysis, or a full sort. The same source file can create very different CPU and memory loads depending on the operation.
- Check whether processing is incrementalA viewer that reads only needed ranges or uses streaming can handle larger files more gracefully. An app that immediately loads the whole file into an ArrayBuffer and creates several intermediates will have a higher peak memory requirement.
- Check the device and failure behaviorPhones may have less headroom than desktop PCs. For long operations, also look for progress, cancellation, retry behavior, and whether the app preserves the selected input after a failure.
Video Compressor
Compress video in your browser with resolution and bitrate controls.
Tips and limitations
- Being able to open a file is different from being able to transform it. Reading metadata can be cheap while re-encoding every frame is expensive.
- For high-resolution images, decoded pixel dimensions can influence memory far more than the compressed JPEG or WebP file size.
- Workers mainly protect UI responsiveness. They do not guarantee less processing time or lower memory use.
- Chunked and streaming processing help, but some formats and operations still require random access or whole-file context.
- Other tabs and applications share the device’s memory. The same file can behave differently depending on the device’s current workload.
Frequently asked questions
Can a browser handle a 1 GB file?
Sometimes, but the 1 GB number alone is not enough to decide. A viewer that reads only needed ranges has a very different memory profile from a tool that loads, decodes, and transforms the entire file. Device, browser, format, operation, and implementation all matter.
Does selecting a file immediately use the same amount of RAM as the file size?
Not necessarily. File / Blob objects represent the selected data and an app can read ranges later. Memory use rises when the app reads the whole file into an ArrayBuffer, decodes it, or creates intermediate and output buffers.
Do Web Workers make large-file processing safe?
Workers help keep heavy work off the main thread so the interface remains responsive, but they do not eliminate memory pressure or CPU cost. Other design choices, such as transferring ArrayBuffers instead of copying them, still matter.
Does WebAssembly give a web app the same large-file limits as a desktop app?
Not necessarily. WebAssembly makes it practical to run efficient processing engines in the browser, but browser sandboxing, memory management, available APIs, and device performance still apply. Wasm alone does not guarantee large-file capacity.
Is a large video slow only because the file is large?
File size is only one factor. Resolution, duration, frame rate, codec, audio, and the requested transformation all matter. Re-encoding in particular requires decoding frames, processing them, and encoding the result again.
References
The discussion of incremental file reads, Canvas pixel data, Web Workers and transferable buffers, and WebAssembly linear memory is based on the following specifications and official documentation. Practical memory limits and maximum processable sizes vary by browser, OS, device, and application design.
- W3C File API
- MDN Web Docs ImageData: data property
- MDN Web Docs Blob: stream() method
- MDN Web Docs Web Workers API
- MDN Web Docs Transferable objects
- MDN Web Docs WebAssembly.Memory