Skip to content
Lizely

Dummy File Generator

Create an exactly sized zero-filled, secure-random, or repeated-text file locally for upload, storage, and transfer testing.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Enter a safe file name and an exact whole-number byte size from 1 through 52,428,800.
  2. 2.Choose zero bytes, secure random bytes, or repeated UTF-8 text and provide the text pattern when needed.
  3. 3.Generate the Blob, confirm the exact byte summary and content policy, then download the local dummy file.

About Dummy File Generator

Dummy File Generator creates a local file with an exact byte size and a predictable content policy. Enter a safe file name, specify the whole number of bytes, choose zero bytes, secure random bytes, or repeated UTF-8 text, generate the Blob, verify the displayed byte count, and download it. Construction and downloading happen in the current browser tab. No generated bytes, file name, or text pattern are uploaded to Lizely or sent to another service.

Dummy files are useful for testing upload limits, attachment validation, storage quotas, progress indicators, download handling, transfer time, archive behavior, checksum pipelines, and application error messages. They let a developer reproduce a file-size condition without searching for a real document that happens to match the required size. This tool creates test material only. It does not emulate a valid image, PDF, archive, executable, media stream, or application-specific file format merely because the chosen name uses that extension.

The requested size is expressed in exact decimal bytes. It must contain digits only, with no sign, decimal point, exponent, comma, unit suffix, or surrounding whitespace. The smallest file is one byte. The largest file is exactly 52,428,800 bytes, equal to 50 MiB. That exact boundary is accepted and the next byte is rejected. The generated parts are summed before publication, and the browser Blob size is checked again against the requested value. Input fields do not impose a hidden HTML length cap: an over-budget value remains visible so generation can report the applicable error. Nothing is silently rounded to kilobytes, shortened, expanded, sampled, or capped.

Zero mode produces only byte value 0x00. The implementation allocates bounded parts rather than relying on a textual null character or a sparse-file feature. The downloaded Blob is a normal file whose logical byte count is the requested size. File systems, browsers, transfer tools, or archives may store or compress long zero runs efficiently, so physical disk usage or compressed transfer size can differ from the logical Blob size. The summary reports logical bytes, not filesystem allocation blocks.

Random mode uses the browser Web Crypto getRandomValues API supplied to the generator through an injectable fill function. Calls are split into chunks of at most 65,536 bytes, respecting the browser API boundary and avoiding one oversized random request. Every chunk is filled before it becomes part of the Blob. Random mode is useful for incompressible test data and checksum tests, but the tool does not retain a seed and cannot reproduce the same random file later. It is not a password generator, encryption system, secure erasure tool, key derivation function, or proof that downloaded bytes remain secret after sharing.

Text mode encodes the entered pattern as UTF-8 and repeats its bytes toward the requested size. Complete pattern repetitions are used first. If the remaining space can hold only a prefix, the tool includes the longest prefix that ends on a complete Unicode code point. Any leftover one-to-three bytes that cannot hold the next complete character are filled with ASCII spaces. This policy preserves valid UTF-8 while still producing exactly the requested byte count. A one-byte request with an emoji-only pattern therefore becomes one space instead of an invalid fragment of the emoji. The visible summary discloses repeated UTF-8 text, and the help text explains final padding.

The text pattern must be nonempty, no longer than 10,000 UTF-16 code units, and free of unpaired Unicode surrogates. Valid emoji and supplementary characters are accepted. UTF-8 byte length is not assumed to equal JavaScript string length because ASCII, accented letters, CJK characters, and emoji use different byte counts. Tests decode generated text files with fatal UTF-8 validation to prove that boundary padding does not leave a broken final sequence. Text mode does not add a byte-order mark, automatic newline, MIME header, or hidden metadata.

File names are validated instead of silently sanitized. Empty names, leading or trailing whitespace, dot paths, forward or backward slashes, slash lookalikes, C0 and C1 controls, zero-width or bidirectional formatting controls, Unicode line separators, and punctuation reserved by common file systems are rejected. Names ending with a dot and Windows device names such as CON, NUL, COM1, and LPT1 are also rejected. The accepted file name is used unchanged as the download attribute. This prevents a request that appears to be a simple name from becoming a path or a misleading direction-controlled label. It does not guarantee that every operating system accepts every remaining Unicode name.

Generation is deferred to a browser task so the busy state can render before byte construction begins. Editing the name, size, pattern, or text increments a job generation, cancels pending work, clears old success and error state, and revokes the prior ObjectURL. Starting another generation performs the same cleanup. If a stale task reaches URL creation, it revokes that new URL immediately rather than publishing it. Component unmount cancels the timer and revokes the current URL. An error never leaves an earlier successful download visible.

The generator constructs Blob parts directly and does not use Canvas or toBlob. ObjectURL creation, exact Blob size validation, job ownership, replacement, and unmount are all tracked. The download link points to the current live Blob only. Browser download behavior may rename a file when a same-named file already exists or when platform policy rejects a name; that external behavior is not a change to the generated bytes. Closing or editing the page revokes the in-memory download URL, so regenerate the file if needed.

A dummy file can consume memory and disk space even though the 50 MiB ceiling is conservative. Avoid generating many large files in multiple tabs. Random bytes are usually difficult to compress, while zeros and repeated text can compress dramatically. Do not use generated files to bypass service limits, exhaust someone else's storage, or test systems without authorization. For structured developer data, use JSON Formatter, JSON Minifier, UUID Generator, or ASCII Table as appropriate. This tool intentionally creates raw test bytes rather than semantically valid content.

Methodology & sources

Keep over-budget input visible so validation can reject it explicitly rather than relying on HTML length caps. Reject unsafe file names, including path separators and lookalikes, C0/C1 controls, invisible formatting characters, non-decimal or non-integer sizes, sizes outside 1 through 52,428,800 bytes, and invalid pattern text. Zero mode creates bounded zeroed Uint8Array parts. Random mode requires an injected Web Crypto filler and calls it only with parts no larger than 65,536 bytes. Text mode encodes the pattern with TextEncoder, repeats complete UTF-8 bytes, uses the longest complete-code-point prefix that fits, and pads only an otherwise incomplete final character with ASCII spaces. Sum part lengths, construct a local Blob, require Blob.size to equal the request exactly, and publish a generation-owned ObjectURL. Editing, replacement, stale completion, errors, and unmount revoke URLs and clear old results.

Frequently asked questions

Is the dummy file uploaded or stored by Lizely?
No. Byte generation, Blob construction, ObjectURL creation, and downloading all happen in the current browser tab.
Will the generated file have exactly the size I enter?
Yes. The generator accepts whole decimal bytes, verifies the part total, checks the final Blob size, and rejects anything above 50 MiB without rounding or truncation.
How does repeated text end at an awkward UTF-8 boundary?
It keeps only complete Unicode characters and fills any remaining bytes with ASCII spaces. This preserves valid UTF-8 while matching the exact requested byte count.
Does a .png or .pdf name create a valid image or PDF?
No. The extension is only part of the download name. The content remains zeros, random bytes, or repeated UTF-8 text and does not gain a real format structure.

Related tools

Developer Tools guides

View all