About Software Test Data
Software Test Data is a browser-based utility built to make software testing easier, giving developers, QA engineers, automation testers and other technology professionals practical test files in 127 formats.
Why we built it. Testing regularly needs files with a specific format, size, encoding or defect. Making those by hand is slow, and slower still when what you actually need is an awkward one — a file at exactly the upload limit, a document with a broken header, text in an encoding that trips a parser.
Why we built it. So instead of building fixtures from scratch, you pick a format, choose the options, and download something you can use immediately.
What you can do. 127 formats are ready to generate, across 11 categories: documents and text, structured data, images, audio, video, archives, code, configuration and DevOps files, scripts and OS packages, eBooks and 3D.
What you can do. Depending on the format, you can produce files for:
What you can do. Testing file uploads and downloads; Testing size limits and storage restrictions; Testing validation and file-processing logic; Checking how an application handles an unfamiliar format; Negative testing with invalid, corrupted or incomplete files; Encoding and compatibility problems, including UTF-16 and byte-order marks; Automated file-processing workflows and CI pipelines; Reproducing a specific edge case during development or QA.
What makes the files different. The aim is not to hand you files with the right extension. Most generators pad a file with random bytes until it reaches the size you asked for, which produces something the right weight that no real application will open.
What makes the files different. Here the padding goes somewhere each format's own specification says readers must ignore: a JUNK chunk in RIFF containers such as WAV and AVI, a PADDING block in FLAC, an ancillary chunk in PNG, an entry's extra field in ZIP-based formats like DOCX and XLSX, or comment lines in text formats. That is why a file can be an exact byte size and still genuinely open.
What makes the files different. And because a valid file only ever proves the happy path, every format can also be produced deliberately broken — invalid, corrupted or incomplete — or structurally correct but empty.
Nothing leaves your machine. Every file is built inside your own browser using standard web APIs and handed straight to its download mechanism. No server of ours ever receives it: there is no upload step and no account to store it against, so we cannot see what you generate even if we wanted to.
Nothing leaves your machine. The sample values are fabricated. Email addresses use example.com, which RFC 2606 reserves for documentation and testing; phone numbers come from ranges set aside for fictional use; card numbers are the published test values that payment processors document for this purpose. Personal names are ordinary placeholders rather than anyone's records. None of it is drawn from real data, so the output is safe to commit to a repository or attach to a ticket.
How the output is checked. A checker written by the same author as the writer will agree with it whether or not either is right. So the generated files are verified against implementations that are not ours: real Java for JAR and WAR, Pillow, pyarrow, mido and plyfile for images and data formats, LibreOffice and Microsoft Office for the document formats, and the W3C's own epubcheck for EPUB.
How the output is checked. Several real defects were found that way and no other — a presentation that opened as thousands of slides, a 3D mesh whose rows were in the wrong order, an eBook using the wrong document type. That is the point of testing against a stranger's implementation.
Who it is for. Anyone who needs dependable sample files while building or testing software: QA engineers, developers, automation and DevOps teams, and students learning to test.
Who it is for. The files suit functional, integration, automation, validation and upload testing, and the larger sizes are useful for performance and limit testing.
Our mission. To make testing easier by giving developers and QA engineers dependable test files for real scenarios, including the awkward ones — a file at exactly the upload limit, a document with a broken header, text in an encoding that trips a parser.
Our mission. Every hour not spent hand-building a fixture is an hour spent actually testing the thing you are building.
Our vision. To be the resource people reach for when they need a specific file to test against, and to be trusted because the files genuinely open in real software rather than merely weighing the right amount.
Our vision. Format coverage and capability keep growing based on what testing actually needs and what people ask for.
Our approach. The tool stays free, needs no account, and is kept deliberately plain. Formats and capabilities are added based on what testing actually requires and on what people ask for.
Our approach. If something is wrong, if a format you need is missing, or if you have an idea for making it better, please say so — feedback is what decides what gets built next.
Contact. Questions, suggestions and bug reports are all welcome at softwaretestdata@gmail.com, or through the contact page. The bug report page asks for the steps and the format involved, which is the difference between a report that can be fixed and one that cannot.
Contact. Thank you for using Software Test Data — we hope it saves you time.