What this tool does
Build a field configuration, choose a row count, and generate. Everything runs in your browser, so nothing is uploaded and no account is required.
Twenty-five field types come from Faker: names, emails, addresses, dates, finance, commerce. Eight more are specific to testing and exist because realistic data alone does not find defects.
How to use it
- Add fields, or start from a preset. Six presets cover the shapes most teams need
- Set the row count, the seed and the locale
- Generate, then export as JSON, CSV or SQL
The preview shows the first twenty rows. The full set stays in memory and reaches you through download, because a hundred thousand rows in the page would make it unusable regardless of how fast they were generated.
Reproducibility, and why the version matters
The same seed and the same configuration produce the same dataset. That is the point of a seed.
But recording only the seed is not enough. If the generator library changes its output between versions, the same seed produces different data and nobody notices until a defect cannot be reproduced. So this tool records the generator version alongside the seed, stamps both into every export, and encodes both in the share link.
That distinction matters because test data is part of the defect evidence, not merely test setup.
A defect report should carry the exact input data, the seed, the generator configuration, the generator or library version, the application build, the environment, and the user, transaction or correlation ID. Without those, the same steps can produce a different result whenever identifiers, dates or generated combinations change.
"It passed on my machine" is often not a machine difference at all. It is that every machine generated a different dataset.
A test is not fully reproducible when you know the steps but cannot recreate the data state. When a failure cannot be recreated, the first question is not what the steps were. It is what exact data and data state produced it.
What to do with that
Log the seed and the exact generated values for every failed automated run. For critical business flows, keep small version-controlled fixtures for known regression scenarios.
Generated data gives you breadth. Frozen fixtures give you certainty on the defects that matter. Both, for different jobs.
Realistic is not the same as effective
Faker produces values that are valid, readable and comfortable for the application. Production users do not.
Teams commonly test normal names, valid email addresses, reasonable dates, short addresses and positive numbers. What gets missed is everything else:
Empty strings, whitespace-only values, null, and missing fields, which are four different things and are frequently treated as one. Maximum-length values and values past the maximum. Unicode, including Telugu, Hindi, Arabic and other scripts. Right-to-left text. Apostrophes and hyphens in surnames. Emoji. Leading and trailing spaces. Line breaks. Duplicate values where uniqueness is assumed. Zero and negative numbers. Very large identifiers. Invalid dates, leap days and time-zone boundaries.
Identity and profile systems must not assume every person has a short English name. API and database testing needs values that expose encoding problems, truncation, fixed-width column limits, serialisation issues, client-side numeric limits, and validation that differs between services.
The combination problem
Data can be individually valid and invalid as a set. An end date before a start date. An age inconsistent with a date of birth. A country and document type that cannot occur together. A status that requires fields the record does not have. Duplicate identifiers where uniqueness is expected.
Every field passes on its own. The row is still wrong.
So a generator should deliberately produce valid common data, valid unusual data, boundary data, invalid data, and internally inconsistent data. If generated data always looks clean, the suite mainly proves the system works when users behave exactly as expected, which is not what production looks like.
Where boundary testing is worth the effort
It is worth it when a field has a defined minimum or maximum, when a database column size differs from the API limit, when one system uses a different numeric type from another, and when dates affect eligibility, expiry, billing or validity.
Also when pagination, file size, transaction limits or batch limits are involved. When a defect would touch financial, identity, signing, security or compliance data. When a value passes through multiple services or technologies. When a client may not safely hold a server-side value. And when previous defects occurred near the same boundary.
Where it becomes theatre
When every theoretical boundary is tested without considering business impact. When the suite has many edge cases but misses the actual consumer assumptions. When teams count cases rather than evaluate risk.
When boundaries are tested only at the UI while the API and database accept different values. When a test asserts only that an error occurred, without checking that it was the correct error and that the system state is right. When invalid inputs are tested but partial data creation and side effects are ignored.
Teams also over-test. Repeating many values from the same equivalence class. Testing every number between minimum and maximum. Hundreds of similar invalid cases carrying no different business risk. UI-level validation already covered better at the API or unit level. Low-risk theoretical combinations while critical integration paths stay uncovered.
Where negative tests belong
Critical negative cases run with the main regression suite. They should not sit in a separate suite that nobody runs before release.
Large destructive, security or specialised datasets can run in separate stages. A workable layering is fast critical positive and negative checks during pull request validation, broader boundary and integration tests after deployment, and heavy or long-running tests on a schedule.
Placement should follow execution cost and risk, not whether a test is positive or negative. That distinction is about how the test reads, not about what it costs to run or what it protects.
If your test data is all valid
Valid-only data proves the happy path and nothing else.
Add a case below the minimum, at the minimum, above the minimum, at the maximum and above the maximum where each applies. Add missing, null, empty and whitespace separately, because they are different. Add invalid field combinations, not only invalid fields. Add values that are technically valid but unusual. Add values that expose differences between the UI, API, database and downstream consumers.
Then check more than the error message: the HTTP status, the error code, the database state, the audit record, retry behaviour, partial processing, and downstream side effects.
A suite containing only valid data is a demonstration, not a test suite. Happy paths show the system can work. Boundary and negative tests show whether it can fail safely.
Every important input deserves at least one meaningful invalid or boundary condition. But do not add edge cases to increase the count. Add the ones most likely to expose data loss, incorrect acceptance, incorrect rejection, truncation, precision loss, security gaps, integration failures or inconsistent state.
A good test dataset makes the system uncomfortable in controlled and repeatable ways.
The eight QA field types
These are why this tool exists rather than being another Faker wrapper.
Sequential ID for predictable identifiers. Boundary integer for zero, minus one, 2^31, 2^53 and the type maxima, selectable so you generate the boundaries that match the system under test rather than all of them. Boundary date for the epoch, leap days, DST transitions and 2038. Naughty string for Unicode, right-to-left, zero-width characters, emoji and encoding edge cases. Weighted custom list for realistic distributions. Regex-derived for format-constrained values. Null-injected and duplicate-injected wrappers for injecting missing values and collisions at a chosen rate.
These are boundary value analysis and equivalence partitioning, made generatable. The concepts reduce risk and avoid duplication; the terminology is not there to make a test plan sound formal.
Limitations, stated plainly
One hundred thousand rows maximum. Generation runs in a worker so the page stays responsive, and cancelling keeps the rows already produced.
Six locales, loaded on demand: English, English (India), German, French, Japanese and Arabic. A field with no data in the chosen locale falls back to English and says so.
CSV exports are altered when values could execute. A value beginning =, +, - or @ runs as a formula when opened in a spreadsheet, so those values are neutralised on export. The CSV therefore differs from the JSON, and the tool tells you when it happens.
Card numbers are test-range only and Luhn-valid. Never plausibly real.
Built by Qortex Lab. Everything runs client side, so your configuration and your data stay in the browser.