A dummy file is a file of an exact, pre-set byte length filled with a chosen content pattern — zeros, secure-random bytes, or a repeating UTF-8 text — that you generate locally to test file-handling code without uploading anything. Developers reach for these placeholder files to reproduce upload-limit errors, validate attachment size rules, measure progress bars under load, time transfer throughput across networks, exercise checksum pipelines, and reproduce disk-quota conditions without hunting for a real document that happens to match the required size. They are best understood as controlled test material: predictable in length, predictable in content policy, and disposable after the test runs. The Dummy File Generator turns this idea into a one-page workflow that runs entirely in your browser tab — every byte is constructed in JavaScript using the browser's Web Crypto API for randomness, downloaded as a normal Blob with a logical byte count you can verify, and never sent across the network. That local-first design lets you generate specific filenames, exact sizes up to 50 MiB, and either compressible or incompressible content on demand, which matters when the test environment forbids uploading real customer data or even fake-looking data to a remote service.
What a Dummy File Does and Doesn't Contain
A dummy file is a controlled test artifact whose content has no semantic meaning. The bytes are chosen for predictable size, predictable compression behaviour, and repeatable characteristics across runs, not for being readable or meaningful. When you set the file name to something like report.pdf or photo.png, the extension travels through to the download attribute unchanged, but the body remains whatever content mode you picked. In other words, a photo.png generated as zero bytes is not a valid PNG file even though the extension is .png — it is a 100-byte stream of 0x00 values with a recognisable name, which is exactly what makes it useful for testing how an application reacts to a wrong format behind a plausible extension.
This separation between name, extension, and actual content is critical when reproducing error paths. Real test photographs often look too realistic to upload into staging environments, and real PDFs may carry metadata that production validators reject. A dummy file sidesteps both problems: it has whatever size you ask for and whatever content policy you select, with no embedded metadata, no MIME hint, and no hidden structure that could trip an unrelated validator.
Three Content Modes and Their Trade-offs
| Mode | Content | Compresses easily? | Best for |
|---|---|---|---|
| Zero | Every byte is 0x00, written into bounded Uint8Array parts | Yes, dramatically | Reproducing upload limits, quota errors, low-entropy payload sizing |
| Secure random | Crypto.getRandomValues bytes in chunks of at most 65,536 bytes | No, incompressible | Worst-case transfer times, checksum pipelines, hash determinism |
| Repeated UTF-8 text | A entered pattern encoded with TextEncoder and repeated to fill the exact size, padded with ASCII spaces at incomplete UTF-8 boundaries | Heavily | Reproducible content shape, line-based parsers, text fixtures |
The choice between these modes changes how the file behaves on the wire and on disk. Zero and repeated text both compress aggressively; a 50 MiB zero file can transfer as a few kilobytes if the transport applies gzip or a similar encoder. Secure random bytes, by contrast, are deliberately incompressible — every chunk is filled with values from the Web Crypto API before it joins the Blob, so the resulting file measures transfer throughput honestly and feeds reliable input to checksum algorithms like MD5, SHA-1, and SHA-256.
If you need the same logical size but predictable bytes — for instance, to compare checksums across runs — zero mode is the most reproducible. If you need the same logical size but high entropy, secure random is the right choice. Repeated text sits between the two: it gives a recognisable byte sequence that still pads to the exact requested size, which is helpful when you want to scan log lines or diff consecutive test downloads.
Build and Download the File
The generator accepts three inputs, builds the file in a series of bounded parts, then publishes a Blob whose size is checked against your requested byte count before the download link goes live. The whole build runs as a deferred browser task so the busy state renders before byte construction begins.
- Enter a safe file name. The name is validated, not silently sanitized — empty strings, leading or trailing whitespace, forward or backward slashes, slashes disguised with lookalike characters, C0 and C1 control codes, zero-width and bidirectional formatting characters, Unicode line separators, Windows device names like CON, NUL, COM1, and LPT1, and names ending with a dot are all rejected so an error appears immediately instead of producing an unsafe download later.
- Enter the byte size as a whole decimal number between 1 and 52,428,800 (the exact ceiling equal to 50 MiB). Digits only — no sign, decimal point, exponent, comma, unit suffix, or surrounding whitespace. The boundary value 52,428,800 is accepted; the next byte, 52,428,801, is rejected. Over-budget numbers stay visible in the input rather than being clipped by an HTML length cap, which lets the generator report the rejection explicitly.
- Choose a content mode. For zero bytes, no further input is required. For secure random bytes, no further input is required — the generator pulls randomness from the browser's Web Crypto API in chunks up to 65,536 bytes per call. For repeated UTF-8 text, type a non-empty pattern up to 10,000 UTF-16 code units, free of unpaired surrogates; emoji and supplementary plane characters are accepted because TextEncoder turns them into their multi-byte UTF-8 representation.
- Generate the Blob. The byte parts are summed in memory, the final Blob's size is verified to equal the requested number exactly, and an ObjectURL is published to the current download link. The link's download attribute is set to the validated file name so the browser's local save dialog receives the same name you typed.
- Confirm the byte summary displayed next to the download button. The summary reports logical bytes (the value of Blob.size), not filesystem allocation blocks — long zero runs can occupy much less physical disk space than 50 MiB after filesystem-level compression, even though the logical byte count is unchanged.
If you change the file name, the size, the content mode, or the text pattern after a successful generation, the previous ObjectURL is revoked, the old success and error state is cleared, and a new generation runs against the updated inputs. Editing any field increments a job generation so stale tasks that finish after a replacement are recognised and revoked rather than published. The download link always points at the live, generation-owned Blob only.
Size Boundaries and UTF-8 Padding Rules
The 50 MiB ceiling is enforced precisely: a request for exactly 52,428,800 bytes succeeds; a request for 52,428,801 bytes is rejected. The size is expressed in decimal bytes, never in kilobytes or mebibytes, and the validator does not silently round. That means a size like 49,000,000 bytes produces a 49,000,000-byte file, not a 47 MiB or 48 MiB approximation. For testing scenarios where the production system enforces a non-round limit such as "files up to 49 MB", entering 49,000,000 bytes is the exact way to reproduce the boundary behaviour.
Repeated-text mode adds a complication that pure zero and random modes do not: bytes per character vary. ASCII letters take one byte each, accented Latin letters like "é" take two, CJK characters typically take three, and emoji and supplementary plane characters take four. The generator encodes the entered pattern as UTF-8 with TextEncoder, repeats the resulting byte sequence until it reaches the requested size, and then handles the awkward remainder with a specific policy.
Here is one concrete boundary case. Enter the pattern "é", which encodes to the two-byte sequence C3 A9 in UTF-8, and request a size of 5 bytes. Two full repetitions consume 2 × 2 = 4 bytes. The remaining 1 byte cannot hold another "é" because that character needs 2 bytes — no prefix of the pattern fits in 1 byte, since the smallest complete code point in the pattern is itself 2 bytes long. The generator therefore pads the remainder with exactly one ASCII space (0x20), producing 4 + 1 = 5 bytes total and a valid UTF-8 file. If the request had been 6 bytes, the generator would have produced three full "é" repetitions and no padding, because the third repetition fits completely. Tests confirm that fatal UTF-8 validation succeeds on every padding boundary, so the bytes always round-trip through a strict UTF-8 decoder.
The same rule lets you create a one-byte file from an emoji-only pattern. A 1-byte request for a four-byte emoji like 🚀 (U+1F680, encoded as F0 9F 9A 80) cannot contain even a prefix of the emoji, so the file becomes a single ASCII space instead of an invalid byte fragment. The visible summary discloses the repeated-text policy and the help text explains the final padding, so this is not a silent substitution.
What Stays in Your Browser
Byte construction, Blob assembly, ObjectURL creation, and download all happen in the current browser tab. No generated bytes, no chosen file name, and no entered text pattern are sent to a remote service or to Lizely's servers. The random-mode generator pulls values from the browser's Web Crypto API, which is filled in chunks of at most 65,536 bytes per call — the size respected by the underlying API — after which the buffer is appended to the Blob.
File name validation is strict because the validator does not rewrite unsafe characters; it rejects them. The accepted name is used unchanged as the download attribute, which prevents a request such as ../report.pdf from silently becoming a relative path. Even after validation, the browser's own download handler may rename or refuse a name if the operating system rejects it — that external behaviour does not change the bytes that were generated.
Closing the page or editing the inputs revokes the in-memory download URL, so if you keep the generator open across long sessions, regenerate the file before any download rather than relying on a stale ObjectURL. The 50 MiB ceiling is conservative, but the generator still allocates real memory while building the file, so avoid opening dozens of large-generation tabs at once. Random-mode files are also harder to compress on disk; zero and repeated-text files can compress dramatically. Do not use generated files to bypass service limits, exhaust someone else's storage, or test systems without authorisation. For structured developer data such as JSON payloads or unique identifiers, the JSON Formatter and UUID Generator are better suited than a raw byte file.
Matching the File to a Testing Scenario
The content mode you choose should match what the system under test actually does with the bytes. Compression-aware upload pipelines, checksum pipelines, and progress-bar timing tests behave very differently on highly compressible zero streams than on incompressible random streams, so the qualitative row below points you to the right mode and the generator confirms the exact figures.
| Scenario | Recommended mode | Why |
|---|---|---|
| Validate an upload size limit at the application layer | Zero | Logical size is exact; file compresses cheaply through HTTP |
| Reproduce a customer "file too large" error message | Zero | Fastest generation, predictable block alignment |
| Time transfer throughput on a saturated link | Secure random | Incompressible payload reflects real-world timing |
| Generate a known hash for a checksum test | Secure random | Entropy is uniform; checksums match the byte stream exactly |
| Reproduce a quota-error message at exactly N MiB | Zero or repeated text | Easy to step through multiple boundary values |
| Feed a line-based parser a recognisable fixture | Repeated UTF-8 text | Lines are predictable and diff-able; padding lands on character boundaries |
| Compare a "valid PNG by extension" path against a real PNG validator | Any mode with a .png name | The bytes are not a real PNG; the extension is just the download name |
For developers who want a single source of reproducible test material across machines, repeated text is the easiest option — every run produces the same bytes for the same size and pattern. For developers who need entropy, secure random is the only choice. For developers who need a file shaped exactly like an upload limit, zero is the smallest, fastest, and most predictable. All three modes run through the same Dummy File Generator workflow, and switching modes never requires re-uploading a reference file or seeding an external dependency.