Sample File Generator

Why You Need a Dummy File Generator (and What Makes a Good One)

If you've ever needed a 100 MB PDF to test an upload limit, a 1 GB binary blob to benchmark S3 throughput, or a perfectly-sized 5 KB JSON to fit a CDN edge cache, you already know the pain: half the "fake file" sites on the web hand you a renamed text file that any decent virus scanner or strict file-type validator will reject. This tool generates files with real format-correct headers, so a PDF really starts with %PDF-1.4, a ZIP really starts with PK\x03\x04, and a WAV really starts with RIFF....WAVEfmt.

Common Use Cases

• Upload-size validation — Test that your form rejects 11 MB when the cap is 10 MB, and accepts 9.99 MB.
• Storage quota testing — Fill an S3 bucket, Azure Blob container or Google Cloud Storage prefix with predictable-size objects.
• CDN / edge cache behavior — Verify that files above your cache-size threshold bypass the cache as expected.
• Network throughput benchmarks — Time downloads of a known-size BIN over different connections.
• Email attachment limits — Confirm Gmail's 25 MB cap, Outlook's 20 MB cap, or your own SMTP gateway rules.
• Database BLOB limits — Push a 16 MB+ binary into MySQL LONGBLOB or PostgreSQL bytea to test driver behavior.
• Container / VM disk fill — Generate a 4 GB BIN to simulate disk-full conditions in CI.
• QA fixture data — DOCX / XLSX / PDF samples for automated regression tests that need "a real Office file".

How Exact-Byte Sizing Works

For every supported format the tool uses a different in-spec padding mechanism so the final file is exactly the size you asked for — not the nearest power of two, not "approximately":

• Text formats (TXT, MD, LOG, CSV, TSV, JSON, XML, YAML, HTML, SQL, JS, CSS, SVG) — Padding goes inside a legal comment, string literal or whitespace region. The output still parses cleanly as JSON / valid HTML / a working SQL file.
• PDF — Comment lines (%) after %%EOF; PDF readers ignore trailing bytes after the end marker.
• PNG — A single tEXt ancillary chunk holds the padding with a proper CRC-32. The image still decodes.
• JPG — Chained FFFE COM (comment) markers between SOI and EOI. Each marker holds up to 65,533 bytes; multiple markers are chained for larger sizes.
• GIF — A Comment Extension block (21 FE) with sub-blocks of up to 255 bytes each.
• WAV — 44-byte RIFF / fmt / data header, then N bytes of 16-bit PCM silence. The file plays as silence in any media player.
• MP3 — Large ID3v2 padding tag followed by a single minimal MP3 frame so audio players recognize the file.
• MP4 — Minimal ftyp + free box, where free is the ISO BMFF-standard padding atom.
• ZIP / DOCX / XLSX — A STORE-compressed (no compression) entry whose body length is computed exactly so the central directory ends on the requested byte. DOCX / XLSX include the minimum Office Open XML parts so MS Word / Excel will open them without errors.
• BIN — Raw Uint8Array filled with crypto-quality random bytes or zeros — no overhead at all.

In-Memory vs Streaming (Why You Want Both)

Generating a 100 MB file by allocating a single Uint8Array(100_000_000) works fine. Generating a 3 GB file that way will crash the tab — V8's heap usually tops out around 2 — 4 GB, and ArrayBuffers larger than ~2 GB are rejected outright by some browsers. The Stream to disk checkbox uses the File System Access API (showSaveFilePicker) to write 1 MB chunks straight to disk, never holding the full file in memory. Supported in Chrome, Edge and Opera (~74% of global users); Safari and Firefox fall back to the in-memory path.

Limitations & Caveats

Be aware of the following constraints before relying on the output for anything beyond size / quota validation:

• In-memory cap: 200 MB per file. Above this the tab risks an out-of-memory crash. Use Stream to disk for anything larger.
• Streaming cap: 5 GB per file, and only for BIN, TXT and WAV. Other formats need the whole byte stream to compute offsets / CRCs and cannot be streamed.
• Streaming requires Chromium (Chrome, Edge, Opera, Brave, Arc). Safari and Firefox do not implement showSaveFilePicker yet.
• Quantity: 1 — 20 per batch (in-memory). Streaming generates one file per save-picker invocation.
• Format minimum sizes (auto-rounded up with a warning): PDF 480 B · ZIP 170 B · DOCX 1.6 KB · XLSX 2.7 KB · PNG 120 B · JPG 300 B · GIF 60 B · WAV 44 B · MP3 42 B · MP4 32 B. All other formats accept any size from 1 byte.
• Output is always UTF-8 for text formats. Other encodings are not currently supported.
• Images are 1×1 pixels. PNG / JPG / GIF reach the requested size by padding metadata chunks — they are not visually meaningful test images.
• MP3 / MP4 are containers, not playable media. MP3 contains one ~32-byte silent MPEG frame after a large ID3v2 padding tag; MP4 contains an ftyp box plus an empty free box with no media tracks. Most players will detect a valid file but play nothing.
• PDF padding is written after %%EOF. Every mainstream PDF reader (Acrobat, Preview, browser viewers) ignores trailing bytes. Strict PDF/A validators may flag this.
• Recent Downloads are kept only for the current tab session and capped at 8 entries. Refreshing the page clears them. The in-browser Re-download button only works on files generated in-memory (streamed files are not re-buffered).
• SHA-256 is skipped for streamed files to avoid doubling the I/O cost. Compute the hash with shasum -a 256 file.bin after the download finishes if you need it.
• Seed affects only the dictionary order of "Realistic" text content. The Random bytes style always uses crypto.getRandomValues (non-reproducible by design).

Privacy & Safety

Everything happens client-side — no upload, no analytics on the generated bytes, no server round trip. The files contain only random or zero data; there is no executable code, no macro, no script payload of any kind. They are bit-for-bit safe to use as fixtures in CI, share with QA teams, or commit to a test-data repo.