Getting started

Three steps from empty page to a realistic dataset β€” plus a few tricks (seeds, blank percentages, patterns) that make the data genuinely useful for testing.

1 Β· Design a schema

The schema builder is a list of fields. Each field has a name (which becomes the JSON key, CSV column or SQL column), a type from the field type reference, per-type options, and a Blank % that injects nulls at that rate β€” perfect for testing how your app handles missing data.

Not sure where to start? Use Load a template… for ready-made schemas: users, e-commerce orders, employees, IoT sensor readings or bank transactions. Your schema is auto-saved to localStorage, so it survives a refresh.

2 Β· Configure rows, format and seed

Pick 1 to 100,000 rows and one of six formats. A quick cheat sheet:

  • CSV / TSV β€” spreadsheets, BI tools, COPY imports. Optional header row.
  • JSON β€” a pretty-printed array; drop it into a mock API or fixture file.
  • NDJSON β€” one object per line; streams nicely into jq, Elasticsearch or BigQuery.
  • SQL β€” INSERT statements with an optional CREATE TABLE whose column types are inferred from your fields.
  • XML β€” <records><record>… for legacy integrations.

The Seed field is the power feature: any string (a ticket number, a build id) makes generation deterministic. Same seed + same schema = byte-identical output, today and in six months. Leave it empty for fresh random data on every run.

3 Β· Export

Download ↓ saves a file named like fundata_1000_rows.csv; Copy data puts the full output on your clipboard; and Copy schema link encodes your entire schema into a URL you can send to a teammate β€” opening it recreates your exact setup.

To keep the schema itself rather than a sample of data, use Export schema ↓ to save it as a JSON file (and Import schema ↑ to load one back β€” handy for checking a fixture definition into a repo). Or save it under a name in My saved schemas to switch between several schemas in this browser without losing any of them.

Recipes

Seed a Postgres table

-- 1. Choose format: SQL, table name: customers, "Create table" checked
-- 2. Download and run:
psql -d mydb -f fundata_1000_rows.sql

Data-driven tests (Playwright)

// Export JSON with seed "sprint-42" so every CI run uses identical fixtures
import users from './fixtures/fundata_100_rows.json';

for (const user of users.slice(0, 10)) {
  test(`signup works for ${user.email}`, async ({ page }) => {
    await page.goto('/signup');
    await page.fill('#email', user.email);
    await page.fill('#first-name', user.first_name);
    // …
  });
}

Stream NDJSON into jq

jq -s 'group_by(.country) | map({country: .[0].country, users: length})' \
   fundata_10000_rows.ndjson

Good to know

  • Privacy: generation is 100% client-side. Nothing you build here is uploaded anywhere.
  • Sensitive-looking fields are fake: credit card numbers use official payment-gateway test PANs and IBANs are country-length-shaped but not bank-valid.
  • Emails are safe: generated addresses use reserved documentation domains like example.com, so accidental sends can't reach real people.
  • Selectors for automation: every control carries a stable data-testid β€” this site doubles as a practice target, just like its siblings funui.dev and funapi.dev.

Next, choose a complete pattern from the test-data use cases, or review how synthetic values are produced in the privacy and safety methodology.