How to create a very large test file

Large files are one of the few test cases that reliably breaks things: upload limits, request timeouts, memory ceilings, progress bars, antivirus scanners and storage quotas all fail differently at 5 GB than at 5 MB. The problem is getting a file that big without waiting for a download.

There are two honest answers, and which one you need depends on whether the file has to be a real, valid file of some format, or merely the right number of bytes.

Up to 1 GB: generate it here, valid and exact

This generator produces files up to 1 GB, at the exact byte count you ask for, and what it produces is a genuinely valid file of the format you picked. A PDF gets a real cross-reference table. A ZIP opens in a real extractor. An ISO image will mount as a drive.

That matters for anything that parses the file after receiving it. A 1 GB file of zero bytes named report.pdf tests your upload path; it does not test your PDF renderer, your virus scanner or your thumbnailer, because it is not a PDF.

Generation happens entirely in your browser, so a 1 GB file is limited by your own machine rather than by a download over the network.

Why the browser stops around 1 GB

Above roughly 1 GB, the constraint is not this tool and not your available memory. It is the maximum size of a single buffer the browser will allocate to JavaScript.

Measured in Chrome on a machine with 15.7 GB of RAM and 5.6 GB free: the JavaScript heap limit reported 4.09 GB, a 1 GB allocation succeeded comfortably (2 ms to allocate, 297 ms to fill, 599 ms to turn into a downloadable blob), and a 2 GB allocation failed outright with RangeError: Array buffer allocation failed.

The important part of that result is that adding RAM does not change it. It is a cap inside the browser, so a 5 GB file cannot be assembled in memory in a browser tab at all, on any machine. Anyone who tells you otherwise is either streaming to disk or not producing the bytes they claim.

5 GB and above: one command, no download

For sizes past the browser's reach, your operating system will create the file instantly and locally. These all produce a file of exactly the size given.

Windows, Command Prompt or PowerShell (5 GB)

fsutil file createnew test-5gb.dat 5368709120

Linux: instant, and sparse (occupies almost no disk)

truncate -s 5G test-5gb.dat

Linux: instant, and it does reserve the blocks

fallocate -l 5G test-5gb.dat

macOS: sparse with -n, real bytes without it

mkfile -n 5g test-5gb.dat
mkfile 5g test-5gb.dat

Any Unix: writes every byte, slowest but least surprising

dd if=/dev/zero of=test-5gb.dat bs=1M count=5120

The sparse-file trap

truncate and mkfile -n create sparse files: the filesystem records the length without storing the contents, so the file reports 5 GB while occupying almost nothing. That is usually what you want, and occasionally what ruins the test.

It bites when the thing under test cares about physical storage rather than logical length: disk-quota checks, backup tooling, and copies onto a filesystem that does not support sparse files, where it suddenly expands to its full size. Use fallocate or dd when the blocks need to genuinely exist.

The bigger caveat applies to all of these commands: the file is entirely zero bytes. It has no format, so anything that parses, validates, transcodes or compresses it will not behave as it would with real content, and it compresses to almost nothing, which quietly invalidates any test involving compression or transfer size.

Which one to use

• Testing an upload limit, a timeout, or a progress indicator, and the content is irrelevant: use the OS command.
• Testing anything that opens, parses or converts the file: generate a real file of the format instead, at the largest size you can. A valid 1 GB file exercises far more code than an invalid 5 GB one.
• Testing storage accounting or quotas: avoid sparse files, or verify with du versus ls -l that the blocks are real.

Common questions

Can I create a 5 GB file in the browser?

No. A browser caps the size of a single buffer it will hand to JavaScript; a 2 GB allocation fails in Chrome with RangeError: Array buffer allocation failed, regardless of how much RAM the machine has. Around 1 GB is the practical ceiling, which is why this generator stops there.

Is fsutil file createnew fast for very large files?

Yes, it returns almost immediately, because NTFS records the file's length without writing every byte up front. The file still reads back as the full size, filled with zeros.

Why not just rename a small file to look big?

The size is a property of the bytes, not the name, so renaming changes nothing your system will measure. A file has to actually contain the bytes for a size limit to reject it.

What is the largest file this site will generate?

1 GB, though the ceiling is per format: video and the formats assembled as text cap lower, and the size list only ever offers sizes the chosen format can genuinely produce.

Generate a large test file →

Formats mentioned here: ZIP test files · PDF test files · ISO test files · MP4 test files · CSV test files

More guides

How to create an invalid JSON file for testing · How to make a corrupted file for testing · How to test file upload validation · Filename test cases that break real systems · Encoding test files: UTF-16, BOM and Latin-1