How Dummy Files Are Made and Checked
What each generated file contains, how it reaches the exact size you ask for, and which independent tools we used to check it. Where we have not checked a format, this page says so.
Files are built in your browser
The generator runs in your browser tab. It builds the file from bytes in memory, keeps the result in your browser's local storage so the download page can show a preview, and hands it to you as a normal download. Nothing you generate, and no file name or setting, is uploaded to a server. Sizes use binary units: 1 KB is 1,024 bytes and 1 MB is 1,048,576 bytes.
Every format has a minimum size, because the smallest valid file of that type has a fixed structure. The tool rejects anything smaller.
Last verification run
We ran npm run verify:generators -- --quick on
. The script calls the same generator code the site ships,
writes each file to disk, checks the exact byte size, and runs the validators for that format.
- 17 formats have a validator: PDF, CSV, JSON, XML, TXT, SVG, DOCX, XLSX, PPTX, ODT, ZIP, TAR, GZ, TAR.GZ, 7z, RAR and ISO.
- 155 of 155 runs passed, 0 failed, and 0 checks were skipped. Each run is one format at one size.
- PNG, JPG/JPEG and WEBP are drawn on a canvas, so they are checked in a real browser:
npm run verify:imagesran on in headless Microsoft Edge and passed 520 of 520 cases. It covers SVG too, at sizes from 1 x 1 to 8192 x 8192 pixels, the minimum size for each width and height, and the exact byte count. The browser must decode each file at the requested width and height, and our own checkers walk the PNG chunks and their CRCs, the JPEG markers and the WebP RIFF chunks. - Sizes per format: the minimum, the minimum plus one byte, 1 KB, 4 KB, 100 KB, 1 MB, 1 MB minus one byte and 10 MB, where each size is inside the format's limits. TAR is only tested at multiples of 512 bytes, and the run also confirms that a size below the minimum is rejected. The quick mode does not include the 100 MB size.
Not independently verified. The other 41 formats have no validator, so we make no claim that their files are valid: .yaml .yml .md .log .sql .tsv .rtf .gif .bmp .tiff .tif .ico .avif .heic .html .css .js .ts .jsx .tsx .php .py .java .c .cpp .cs .go .rs .sh .bat .bin .dat .db .sqlite .img .wasm .har .http .graphql .proto .ndjson. For example, several text and code formats (for example YAML and SQL) are known to produce content that a strict parser rejects; and .bin, .dat, .img, .wasm, .db and .sqlite are filler bytes with at most a file header. We update this date whenever a change touches a generator.
Documents and data: contents, size and checks
| Format | What the file contains | How the size is reached | Checked with |
|---|---|---|---|
| A PDF 1.7 file on A4 pages with text only and document metadata. You choose the exact page count (10 by default, 1 to 200). | A % comment line is appended after the final %%EOF marker to fill the exact byte count. | pdf-lib (strict parse, page count, page size), plus checks for the %PDF- header, %%EOF and startxref. | |
| CSV | A header line plus exactly the rows and columns you choose (5 rows x 10 columns by default), UTF-8 without a byte order mark, CRLF line endings. | The extra bytes become filler text in the last column of every data row, so the row and column counts stay exact and no row is cut short. | Our own checker: encoding, header, CRLF only, exact row and column counts on every line, quoting and sequential ids. |
| JSON, XML, TXT, SVG | JSON is an array of sample records. XML is a dataset of repeated items. TXT is ASCII paragraphs with line breaks. SVG is a small graphic. All are UTF-8 without a byte order mark. | Records, items or paragraphs repeat until the size is close. JSON absorbs the last few bytes as spaces before the closing bracket, XML and SVG use a padding comment, and the last TXT line can be cut short. | Our own checkers: JSON.parse for JSON, a well-formedness checker for XML and SVG (SVG also needs an svg root and namespace), and UTF-8 with line breaks for TXT. Each also confirms the exact byte size. |
| DOCX, XLSX, PPTX, ODT | A small ZIP package with the required parts. DOCX has two paragraphs, XLSX has one sheet with a header and two records, ODT has one paragraph, and PPTX has no slides. | A stored (uncompressed) padding.dat part carries the extra bytes, so nothing is truncated. | Our own ZIP structure and CRC checker, JSZip with CRC checking, Info-ZIP unzip -t and 7-Zip. Also the required parts ([Content_Types].xml and _rels/.rels for the OpenXML formats; mimetype and manifest for ODT). |
These checks show the files are well-formed packages and documents. The script does not open them in Adobe Acrobat, Microsoft Office or LibreOffice, so we do not claim they open in a particular program. The minimum size is 4 KB for PDF and 4 KB for the four ZIP-based document formats.
Archives and disc images: contents, size and checks
| Format | What the file contains | How the size is reached | Checked with |
|---|---|---|---|
| ZIP | README.txt, sample_manifest.json and archive_payload.dat (zero bytes). Entries are stored, not compressed. | archive_payload.dat grows to fill the requested size. | Our own structure and CRC-32 checker, JSZip, Info-ZIP unzip -t, 7-Zip 24.09. |
| RAR | A RAR5 archive using the store method (no compression) with a README and a zero-filled payload file. | The payload length is searched so the total matches; the README is padded by a few bytes if a size is otherwise unreachable. | Our own RAR5 parser (CRCs), UnRAR (WebAssembly build: list and extract), 7-Zip 24.09, bsdtar 3.7.7. |
| 7z | A 7z archive using the Copy method (no compression) with README.txt and archive_payload.dat. | archive_payload.dat grows to fill the requested size. | Our own header parser (start header and next header CRCs), 7-Zip 24.09 list and test. |
| TAR | A POSIX ustar archive with README.txt and archive_payload.dat (zero bytes). | The archive is built in 512-byte blocks, so only sizes that are a multiple of 512 bytes can be generated. The smallest is 2.5 KB. | Header field and checksum checks, GNU tar 1.35, bsdtar 3.7.7, 7-Zip 24.09. |
| GZ | A gzip file (RFC 1952) built from stored deflate blocks, so it is not compressed. It decompresses to a zero-filled archive_payload.dat. | The stored blocks are sized so that the whole file is the requested length. | GNU gzip 1.14 (gzip -t), Node.js zlib (CRC-32 and length), an independent CRC-32, 7-Zip 24.09. |
| TAR.GZ | A gzip stream of stored blocks around a ustar tar that holds README.txt and archive_payload.dat. | The tar inside is padded to fit; the smallest size is 2.59 KB. | GNU gzip 1.14, GNU tar 1.35 (tar -tzf), bsdtar 3.7.7, 7-Zip 24.09, plus the tar header checks. |
| ISO | A minimal ISO 9660 image (volume name DUMMYFILES) with README.TXT and a zero-filled PAYLOAD.DAT. | PAYLOAD.DAT fills every whole 2,048-byte sector. Any remaining bytes are zeros after the end of the volume. | Our own ISO 9660 parser and 7-Zip 24.09 (listing). It has not been mounted on a real operating system. |
None of these archives are compressed: every entry is stored or copied, so the file on disk is the size you asked for and extracts to about the same size. WinRAR, Windows Explorer and macOS Archive Utility were not part of the run.
What the files are not good for
- OCR and text extraction quality: PDFs hold plain generated text and no scanned pages or images.
- Parser performance: most of a large file is padding, so it says little about how a parser handles a real document of that size.
- Realistic compression ratios: archives store their padding uncompressed, and the padding is all zeros. Real data compresses differently.
- Realistic content: the content is short and repeated. Use a real document that you have permission to use when layout, schema or content matter.
- Sizes for TAR: only multiples of 512 bytes are possible, because tar works in 512-byte blocks.
- Unchecked formats: see the list above. Treat them as filler for size and file-type tests only.
Found a file that does not behave?
If a file fails in a tool that this page says it was checked with, or a claim here is wrong, please contact us with the format, the size and the tool. Read more about Dummy Files.