Guide
How to create a test file of any size (1 GB, 2 GB, 4 GB and more)
One-line commands for macOS, Linux and Windows that create exact-size test files, why random data beats zeros for upload tests, and which sizes break software.
Downloading a 4 GB file to test an upload form wastes time and bandwidth when your machine can write one in a few seconds. This guide covers the commands, the sizes worth testing, and one detail that skews results: whether the file compresses.
If you’d rather not use a terminal, the in-browser generator makes a file of any exact size. Ready-made files up to 500 MB are in Large Files.
The sizes that break things
| Size | Bytes | Why it matters |
|---|---|---|
| 2 GB | 2,147,483,648 (2³¹) | One past the largest signed 32-bit integer. Code that stores a size or offset in an int overflows here. |
| 4 GB | 4,294,967,296 (2³²) | One past the largest unsigned 32-bit integer. FAT32 can’t store a file this big. |
| 4 GB + 1 byte | 4,294,967,297 | The smallest file that crosses both limits. Use this one when you only test one size. |
Also test one byte under your own upload limit and one byte over it, using the same units your server uses. 10 MB can mean 10,485,760 or 10,000,000 bytes.
macOS and Linux
head copies an exact number of bytes from the system’s random source:
head -c 1073741824 /dev/urandom > sample-1gb.bin # 1 GB
head -c 2147483648 /dev/urandom > sample-2gb.bin # 2 GB (2^31)
head -c 4294967297 /dev/urandom > sample-4gb-plus-1.bin # 4 GB + 1 byteIf you only need the file size and not its contents, these commands finish instantly. They create a zero-filled file without writing the data:
truncate -s 4294967297 sample-4gb-plus-1.bin # Linux
fallocate -l 10G sample-10gb.bin # Linux, allocates real disk blocks
mkfile -n 4294967297 sample-4gb-plus-1.bin # macOS, size in bytesWindows
In Command Prompt, fsutil creates a zero-filled file of an exact size. Some Windows versions require an administrator prompt:
fsutil file createnew sample-4gb-plus-1.bin 4294967297In PowerShell, without admin rights:
# Zero-filled, instant
$f = [IO.File]::Create("$PWD\sample-4gb-plus-1.bin"); $f.SetLength(4294967297); $f.Close()
# Random bytes, 1 GB
$b = New-Object byte[] 1MB; $r = [Security.Cryptography.RandomNumberGenerator]::Create()
$f = [IO.File]::Create("$PWD\sample-1gb.bin"); 1..1024 | % { $r.GetBytes($b); $f.Write($b, 0, $b.Length) }; $f.Close()Random data or zeros?
Zeros compress to almost nothing. A 4 GB file of zeros gzips to about 4 MB. That matters whenever something between you and the server can compress the transfer:
- Upload speed and progress bars: if a proxy, VPN or
rsync -zcompresses the stream, a zero-filled file “uploads” far faster than a real one. Use random data. - Size validation: both work. The server sees the full byte count either way.
- Compression and deduplication tests: zeros are the best case and random data the worst, so test with both.
Real uploads are usually already compressed (photos, videos, archives), so random data is the closer match.
Check the file
Confirm the size in bytes before you rely on it:
stat -c %s sample-4gb-plus-1.bin # Linux
stat -f %z sample-4gb-plus-1.bin # macOSOn Windows, run (Get-Item sample-4gb-plus-1.bin).Length in PowerShell.
To check that a file arrived intact after an upload, compare checksums with shasum -a 256 file or the checksum calculator.