What Is a Dummy File? Anatomy, Byte Sizes and When to Use One

A dummy file is a file whose contents are irrelevant to the test but whose type and size are exactly what the test needs. When we test an upload form that says "PDF up to 5 MB", we do not care what the PDF says. We care that it starts with %PDF-, that it is exactly 5,242,880 bytes (or one byte more), and that it contains nothing sensitive. That is the whole job of a dummy file.

This post explains how a dummy file is put together, how to check one before you rely on it, and where it stops being the right tool.

The two parts: a template and padding

Almost every generated test file is built the same way:

1. A minimal valid template. The smallest structure that a parser will accept as the claimed format: a one-page PDF, a 1x1 PNG, an empty ZIP archive, a WAV header with a few samples, and so on. For text formats the template is a few lines of syntactically valid content (a CSV header row, a JSON object, a YAML mapping).
2. Padding that brings the file up to the requested byte count. Where the padding goes depends on the format. Binary formats usually have somewhere a parser will ignore extra bytes (a comment, an unused chunk, trailing data after the end marker). Text formats are padded with whitespace, which most parsers skip.

On our generator that means the following for the 28 supported formats:

• Stay valid when padded: PDF, DOCX, ZIP, JPG, PNG, GIF, WebP and WAV. You can open them in a normal viewer at any size.
• Minimal shells: MP3, MP4 and WebM have the right signature and MIME type, so they pass extension, MIME and size checks, but they will not play. Use them for upload-limit and content-type tests, not for transcoding or playback tests.
• Text formats (TXT, MD, VTT, HTML, SVG, JS, TS, CSS, SCSS, JSON, CSV, XML, SQL, YAML, INI, ENV, TOML) are padded with spaces.

Everything is built in your browser tab; nothing is uploaded to us. The maximum is 512 MiB per file, and the default file name is dummy.<ext>.

Size is the part people get wrong

Most upload bugs we see around dummy files are really unit bugs. "5 MB" can mean two different numbers:

• 5 MB (decimal) = 5,000,000 bytes
• 5 MiB (binary) = 5 x 1024 x 1024 = 5,242,880 bytes

A validator written as size <= 5 * 1000 * 1000 and a UI that says "5 MB" while the storage layer enforces 5 * 1024 * 1024 will disagree for every file between 5,000,001 and 5,242,880 bytes. That is a 242,880-byte window where users get inconsistent results. The only way to test it is with files of exact byte counts on both sides of both numbers. The file size calculator converts between the two if you are unsure which one a spec means.

How to verify a dummy file before you trust it

Before a file goes into a test suite, we check three things: byte count, signature, and that a real parser accepts it.

# Exact byte count (macOS / Linux)
wc -c dummy.pdf
stat -c %s dummy.pdf        # Linux
stat -f %z dummy.pdf        # macOS

# Windows PowerShell
(Get-Item .\dummy.pdf).Length

# First bytes of the file (the "magic number")
xxd dummy.pdf | head -n 2
# 00000000: 2550 4446 2d31 2e..   %PDF-1..

# What does libmagic think it is?
file --mime-type dummy.pdf
# dummy.pdf: application/pdf

If you do not have a terminal handy, the magic-byte sniffer reads the first bytes of a local file in the browser and tells you what the signature says, and MIME lookup tells you what type a given extension is normally mapped to.

For formats that should stay valid, also open the file in the program your users would use. A padded PDF should open in a PDF viewer; a padded ZIP should list its contents with unzip -l. If a "valid" format does not open, do not use it for tests that depend on parsing.

What dummy files are good for

• Size limits. Under, exactly at, and one byte over every limit in the stack: the form, the API, the reverse proxy, object storage. See the 5 MB PDF boundary scenario for a worked matrix.
• Type checks. Does the server look at the extension, the Content-Type header, the magic bytes, or all three? A correct file with the wrong extension is a cheap, safe probe; see extension versus sniffed MIME.
• Timeouts and progress UI. A 24 MB file on a throttled connection takes long enough to watch the progress bar, cancel mid-upload, and see what the retry logic does.
• Quota and storage accounting. Upload a known number of bytes and check that the "storage used" figure moves by exactly that much.
• Import pipelines. A large CSV or JSON file tests whether the importer streams or loads everything into memory.

What dummy files are not good for

Being honest about the limits saves time:

• Rendering and content quality. A padded 1x1 PNG will not tell you whether your thumbnailer handles a 12,000 x 8,000 photo or a CMYK JPEG. Use real sample images for that.
• Media processing. The MP3, MP4 and WebM shells do not decode. If your pipeline runs ffmpeg, you need real media.
• Compression ratio tests. Space padding compresses extremely well. A 100 MB padded text file may gzip to a few hundred KB, which is great for checking that compression is on and useless for measuring realistic transfer size.
• Malware scanning. Dummy files are deliberately benign. For antivirus integration, use the industry-standard EICAR test string, not a random file.
• Data correctness. A padded CSV has a header and a few rows plus whitespace. If you need 50,000 realistic rows to test deduplication, generate rows, not padding.

A short checklist

1. Write down the limit in bytes, not "MB".
2. Generate files at limit - 1, limit, and limit + 1 bytes for every format you accept.
3. Verify byte count and signature locally.
4. Record the expected result for each file (accepted, rejected with which error) before running the test.
5. After upload, compare the stored object size with the original. A 200 response does not prove the bytes arrived intact.

For a longer walkthrough of the generator itself, read how to generate dummy files. For a complete upload test plan, the file upload testing guide goes further.