Three Ways to Get Test Files: Hosted Samples, Browser Generators and CLI Tools

There are three common ways to get a test file of a given size: download a sample someone has hosted, generate one in a browser, or create one with a command-line tool. Each is the right answer in some situations. This post compares them on the questions that actually matter for testing: can you hit an exact byte count, is the file a valid instance of its format, where does data go, and can someone else reproduce it next month.

We build a browser-based generator, so we have a bias. We have tried to keep the comparison factual, and we point out where the other approaches are better.

Option 1: Hosted sample files

Many sites host pre-made files at common sizes ("sample 10 MB PDF", "sample MP4"). You download the one you need.

Where it is strong:

Real content. A hosted sample can be a real video that plays, a multi-page PDF with fonts and images, or a photo with EXIF data. For transcoding, rendering, OCR or thumbnail quality, real content is what you need, and generated padding is not.
No tooling. A link is enough. Anyone can use it.

Where it is weak:

Fixed sizes. You get "about 10 MB", not 10,485,761 bytes. Boundary tests need exact counts.
Bandwidth and time. A 100 MB sample is a 100 MB download, on every machine and every CI run that does not cache it.
Trust. You are running an unknown binary through your parsers. For a staging environment that is usually acceptable; still, record a SHA-256 of the file you tested with so you can tell if the hosted file changes later.
Data flow. Downloading sends ordinary request metadata (IP address, user agent) to the host. Nothing of yours is uploaded, so for most teams this is not a privacy issue.

Option 2: Browser-based generation

A page builds the file in your browser from a small template plus padding and hands it to you as a download. This is how our generator works.

Where it is strong:

Exact sizes. Any byte count, including limit + 1. On our generator that works up to 512 MiB per file, with links like /generator?ext=pdf&bytes=5242881.
Valid formats. On our generator, padded PDF, DOCX, ZIP, JPG, PNG, GIF, WebP and WAV files stay valid, so they pass signature checks and open normally.
No transfer. Nothing needs to be downloaded from a server or uploaded to one, which makes large files quick.
Shareable. A URL that fixes the type and size is a precise, reproducible specification.

Where it is weak:

Content is not realistic. Padding is padding. A padded 1x1 PNG tests size and type rules, not your image resizer. Our MP3, MP4 and WebM outputs are shells that do not play.
Browser memory. Very large files are limited by the tab's memory. That is why we cap at 512 MiB.
Not headless by default. For CI you either commit the files, script the equivalent logic, or use a CLI tool.

How to verify a "client-side" claim yourself: open DevTools, go to the Network tab, clear it, and generate a file. If the file is built in the browser, you will see no request carrying the file (you may see ordinary page or analytics requests). This check applies to any tool that claims to work locally, including ours.

Option 3: Command-line tools

Every operating system can create a file of an exact size with built-in tools:

# Linux (GNU coreutils): sparse file, reads as zero bytes
truncate -s 5242881 over.bin        # exact bytes
truncate -s 5M five-mib.bin         # 5M = 5 MiB; 5MB = 5,000,000 bytes

# Linux: allocate real disk blocks (ext4, xfs and some others)
fallocate -l 5242881 over.bin

# Linux / macOS: write zeros or random data explicitly
dd if=/dev/zero of=zero.bin bs=1M count=5
head -c 5242881 /dev/urandom > random.bin   # incompressible

# macOS
mkfile -n 5242881 over.bin

# Windows (cmd)
fsutil file createnew over.bin 5242881

# Windows PowerShell
$f = [IO.File]::Create("over.bin"); $f.SetLength(5242881); $f.Close()

Where it is strong: exact sizes, no network at all, trivially scriptable in CI, and no practical size limit beyond disk space. For multi-gigabyte files this is the right tool. /dev/urandom gives incompressible data, which matters if gzip or a CDN would otherwise shrink your test file in transit.

Where it is weak: the files have no format. A 5 MB file of zeros named over.pdf will be rejected by any server that checks magic bytes, so it tests the type check rather than the size limit. Sparse files (from truncate or mkfile -n) can also behave differently from normal files in some copy or backup tools.

A common hybrid is to take a small valid file and append or insert padding with a script, which gives exact sizes and valid formats in CI. Our fixture management post shows how to do this for JSON and PNG in Node.js.

Side by side

	Hosted samples	Browser generator	CLI tools
Exact byte count	No	Yes (up to 512 MiB here)	Yes
Valid file format	Yes, real content	Yes for padded templates; media are shells	No
Realistic content	Yes	No	No
Network transfer	Full download	None for the file	None
Scriptable in CI	With a download step	Not directly	Yes
Multi-GB files	Slow	No	Yes

Questions to ask about any tool

Does it need an account, API key or upload of your own files? For making test files, none of these should be necessary.
Can you get the same file again? A URL, a command or a hash in your test plan makes a test reproducible; "the big PDF from last sprint" does not.
Is the byte count exact, and is the unit clear (MB or MiB)? The file size calculator helps when it is not.
Does the file really have the type it claims? Check with file --mime-type or the magic-byte sniffer.

What we use when

Size limits and type checks: a generator with exact sizes and valid templates, or a scripted hybrid in CI.
A common size, quickly: the ready-made pages under /download, for example /download/10mb-pdf.
Rendering, media and OCR: real sample files, pinned by hash.
Multi-gigabyte transfer and storage tests: truncate, fallocate or dd, with /dev/urandom if compression is in the path.

Before choosing sizes, it helps to know which limits you are testing against; /upload-limits lists common service and framework limits.