Sample & Test 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. A test file is only useful if the thing you are testing accepts it as genuine. 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 / PPTX samples for automated regression tests that need "a real Office file".
• Multi-page documents — need a 105-page Word document or a 50-page PDF for pagination, printing, or page-count testing? Set the Pages field (PDF & DOCX) to generate real, separate pages — the file is padded up to your target size if that is larger.
• Negative testing — set the size to 0 for an empty file, or use the Corrupt File Generator for files that are broken on purpose: truncated, password-protected, bad checksums, malformed JSON and more.

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 (%) between the last object and the cross-reference table, so the file still ends with startxref and %%EOF. Readers skip comments. See what's inside a generated dummy PDF below.
• PNG — A private ancillary chunk (skPd) holds the padding with a proper CRC-32. Decoders must skip ancillary chunks they don't recognise, so the image still decodes; a large tEXt chunk would not, because readers such as Pillow cap text chunks.
• 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.
• TIFF — No padding needed in most cases: with Dimensions blank, the image itself grows (4:3) until its uncompressed RGB pixels fill the target, and the last few bytes go after the pixel data, outside every tag. With a width × height set, the size is a minimum.
• WAV — 44-byte RIFF / fmt / data header, then N bytes of 8-bit mono PCM audio (8 kHz): silence with Zero-fill, white noise with Random bytes. Either plays 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, zeros, or the characters 0 and 1 — no overhead at all.

What's Inside a Generated Dummy PDF

PDF is the format people most often need for upload testing, and it is also the easiest one to get wrong. A file that merely starts with %PDF-1.4 will open in a lenient browser viewer and then be rejected outright by Acrobat or by a strict parser such as pypdf. Every dummy PDF this tool produces is a complete document object graph, not a header glued onto random bytes:

• A real object tree — Catalog → Pages → one Page object per page, each with its own content stream.
• Real text on every page — a title, lines of lorem ipsum body text and a “Page 3 of 10” footer. The page holds as many lines as your byte target allows, up to a full page, so text extraction, search indexing and preview thumbnails have something to show. Choose Zero-fill for blank pages or 0s & 1s for pages of binary digits.
• A declared font resource — a Type1 Helvetica object that the content stream actually references. A page that draws text with /F1 but declares no font is the single most common defect in generated PDFs.
• Accurate /Length on every stream — computed from the assembled bytes. A hardcoded or estimated length makes strict readers over-read past endstream and abort with a parse error, even though lenient viewers show the page fine.
• A byte-correct cross-reference table — every xref offset is measured against the finished file rather than predicted, so incremental readers can seek directly to any object.
• Padding in comment lines — any bytes needed to reach your exact size are % comment lines placed before the cross-reference table, so the file still ends with startxref and %%EOF, where Acrobat looks for them.

Set the Pages field to produce a genuine multi-page dummy PDF — each page is a separate Page object with its own content stream, so page-count assertions, pagination logic and print previews behave the way they would against a real document. A large size on a few pages is mostly padding; add pages if you need the bytes to come from content. The same applies to DOCX, where extra pages are real w:br page breaks rather than repeated text.

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 desktop Chrome, Edge and Opera; Safari, Firefox and mobile browsers 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: 20 GB per file for BIN and TXT, and 4 GB for WAV, whose size fields are 32-bit. Only these three formats stream; the others need the whole byte stream to compute offsets / CRCs. Make sure the drive has the space before you start.
• Streaming requires desktop Chromium (Chrome, Edge, Opera, Arc; Brave blocks the API by default). 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 600 B · ZIP 170 B · DOCX 1.6 KB · XLSX 2.7 KB · PNG 120 B · JPG 300 B · GIF 60 B · TIFF 183 B · WAV 44 B · MP3 42 B · MP4 32 B. Structured text has a smallest valid document too: JSON 69 B · XML 114 B · SVG 170 B. A one-slide PPTX is never smaller than its built-in template (about 98 KB). All other formats accept any size from 1 byte. A size of 0 always gives an empty (0-byte) file.
• Output is always UTF-8 for text formats. Other encodings are not currently supported.
• Images: leave Dimensions blank and PNG / JPG / GIF are valid 1×1-pixel placeholders padded to the requested byte size, while TIFF becomes the largest 4:3 image that fits. Set a width × height (PNG / JPG / TIFF) to render a real, viewable image at those exact pixel dimensions — then padded up to your target size if larger. GIF is always 1×1.
• 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.
• A few pages of a big PDF hold the content; the rest is padding. Comment lines fill the gap before the cross-reference table. Every mainstream reader skips them, but a strict PDF/A validator may flag a file that is mostly comments.
• 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 makes a file reproducible: same seed, same bytes. Leave it blank and a new seed is picked for you and shown with the result — Use this seed puts it back in the field so you can make the same file again. It drives "Realistic" text (including PDF page text) and CSV / TSV rows, and fixes the timestamp in JSON, XML, YAML, LOG and ZIP / Office files. Random bytes, and 0s & 1s in TXT / BIN, always use crypto.getRandomValues (non-reproducible by design); the Seed field is disabled wherever it would have no effect.
• Content style options depend on the format. Only the styles that change the output are shown: all four for TXT, LOG, MD, SQL, JS and CSS; Realistic, Zero-fill (blank pages) and 0s & 1s for PDF; Realistic, Random bytes and Zero-fill (black) for TIFF, and for PNG / JPG once a width × height is set; Zero-fill (silence) and Random bytes (white noise) for WAV; Zero-fill and Random bytes for MP4; Random bytes, Zero-fill and 0s & 1s for BIN. The other formats have fixed content.

Privacy & Safety

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