Toolkite

How to Use a Fake Data Generator in 5 Steps (No Signup, Nothing Uploaded)

Oct 31, 2026 · AI-assisted

You need 5,000 rows of plausible customer records for a staging database, and you don't want to hand-type them or hand your schema to a random web service. A fake data generator solves the typing problem; the browser-only part solves the trust problem. Here's the exact workflow I use with Toolkite's Mock Data Generator, plus honest notes on when a CLI tool is the better fit.

Step 1 — Decide what a row actually needs to look like

Before you touch any UI, sketch one row on paper (or in a scratch file). A realistic users row usually needs: an ID, a first and last name, an email that matches the name, a signup date in the last 18 months, a country, and a status field with a small set of values like active, trial, churned.

The temptation is to add twenty fields "just in case." Don't. Every extra field is another column your test fixtures, migrations, and CSV exports have to handle. Start with the minimum a real query would touch.

One edge case worth planning for now: if you'll test pagination or date filters, make sure at least one field is a date and one is numeric. Faker can produce both, but only if you actually list them in the schema.

Step 2 — Build the schema in the browser

Open the Mock Data Generator and add a field for each column you decided on. Pick the field type from the list — name, email, address, date, and so on. The free tier covers a solid set of common types; if you need locale-specific names or addresses, that's where the optional Pro tier ($14.99 one-time) adds 30+ field types including locale data.

A few practical notes from doing this repeatedly:

  • Name fields are two fields. faker.js treats first name and last name separately, so add both if you want them separate in output. If you only need a display name, one field is fine.
  • Emails should be derived, not random. If your schema lets you reference another field, build the email from the name so jane.cole@example.com doesn't end up paired with a person called Marcus.
  • Dates need a range. A signup date without bounds will scatter across decades and break any "last 90 days" test you write later.

Step 3 — Generate and eyeball the first 20 rows

Set the row count low first — 20 is plenty — and generate. Read them. This is the step people skip, and it's the one that catches schema mistakes before you export 20,000 rows of garbage.

Things to check in that first batch:

  • Do the emails look like they belong to the names?
  • Are dates inside the range you intended?
  • Does the status column only contain values your app actually accepts?
  • Are there any obviously fake-looking placeholders (like test@test.com) that will trip a validation rule?

The free tier allows up to 20,000 rows per generation, which is more than enough for most staging databases. If you need to go bigger, that's a Pro feature — and it's worth asking whether you really need 200,000 rows or whether 20,000 with a loop in your seed script would do.

Step 4 — Export in the format your next step expects

Free exports are JSON or CSV. Pick based on what's consuming the file:

  • JSON if you're seeding a Node script, an API mock, or a NoSQL collection.
  • CSV if you're loading into Postgres via COPY, into a spreadsheet, or into a data tool that wants tabular input.

If you're heading toward SQL, Pro adds SQL INSERT export and multi-format ZIP export — handy when you want the same dataset in two formats without regenerating. Either way, the file is produced locally in your browser; nothing is uploaded to a server. That matters if your schema includes anything resembling real customer field names.

Step 5 — Load it and verify with a real query

Don't trust the export until a query returns what you expect. A quick sanity check:

SELECT status, COUNT(*) FROM users GROUP BY status;
SELECT MIN(signup_date), MAX(signup_date) FROM users;

If the min/max dates are outside your intended window, your schema's date range was wrong — go back to Step 2 rather than patching the data downstream. If status has a value you didn't plan for, the field type wasn't constrained tightly enough.

One more habit worth building: save the schema. Pro lets you store up to 20 schemas in IndexedDB, which means next sprint you regenerate the same shape in one click instead of rebuilding it. The free tier doesn't include saving, so keep a copy of your field list in the repo's test fixtures folder.

The alternative: faker.js from the command line

If you already live in Node, running faker.js locally is a legitimate alternative. A minimal script looks like this:

// seed.js — run with: node seed.js > users.json
const { faker } = require('@faker-js/faker');
const rows = Array.from({ length: 5000 }, () => ({
  id: faker.string.uuid(),
  firstName: faker.person.firstName(),
  lastName: faker.person.lastName(),
  email: faker.internet.email(),
  signupDate: faker.date.past({ years: 1.5 }),
  country: faker.location.country(),
  status: faker.helpers.arrayElement(['active', 'trial', 'churned']),
}));
console.log(JSON.stringify(rows, null, 2));

Trade-offs, honestly:

  • The CLI gives you total control — custom distributions, cross-field logic, weird formats. If your schema needs email derived from firstName + lastName with a specific domain, a few lines of JS beat any UI.
  • The browser tool wins when you don't want to install Node, when a non-developer on the team needs to regenerate data, or when you want a visual schema you can hand to someone else.
  • Both keep data local. Neither sends your schema anywhere.

If you're curious how the browser approach compares to SaaS generators like Mockaroo, the Mockaroo alternative walkthrough covers that ground without repeating it here.

Where this workflow breaks (and what to do)

A few failure modes I've hit:

  • Referential integrity. If your orders table needs user_id values that exist in users, generate users first, export the IDs, and feed them into the second generation. Neither the browser tool nor a naive faker.js script enforces foreign keys for you.
  • Locale-specific data. US-style addresses look wrong in a German test fixture. The free tier's field types are limited; Pro's locale data is the reason to upgrade if you're testing internationalization.
  • PII-shaped data in screenshots. Even fake names in a bug report can look like a leak to a reviewer. If you're pasting screenshots of test data, run them through the EXIF Remover first — not because the data is real, but because the habit is worth keeping.

If you want the privacy reasoning behind browser-only tools in general, the privacy page lays out what Toolkite does and doesn't do with your input.

Quick checklist before you ship the dataset

  • Schema matches the actual columns your app queries
  • Date ranges are bounded and realistic
  • Enum-style fields only contain accepted values
  • First 20 rows read correctly
  • Export format matches the loader (COPY, ORM, spreadsheet)
  • A verification query returns expected min/max and counts
  • Schema saved somewhere your team can find it

That's the whole loop. Five steps, one browser tab, no account, and nothing leaves your machine.

FAQ

Is the fake data generator really free, and what's the catch?

The free tier covers up to 20,000 rows per generation and a limited set of field types, with JSON or CSV export. There's an optional one-time Pro tier ($14.99) that adds unlimited rows, 30+ field types including locale data, schema saving in IndexedDB, and SQL INSERT / ZIP export. No subscription, no account required to use the free tier.

Does my schema or generated data get sent to a server?

No. faker.js runs locally in your browser, so the schema you build and the rows you generate stay on your device. Exports are produced client-side as well. That's the main reason to prefer this over a SaaS generator when your field names resemble real customer columns.

Can I generate related tables, like users and their orders?

Not with automatic foreign-key linking. The practical approach is to generate the parent table first, export the IDs, then use those IDs when building the child table. Neither the browser tool nor a plain faker.js script enforces referential integrity for you.

How do I get SQL INSERT statements instead of CSV?

SQL INSERT export is a Pro feature. On the free tier you can export CSV and load it with your database's bulk import (for example Postgres COPY), which is often faster than INSERT statements anyway for large datasets.

What's the difference between this and running faker.js in Node?

Same underlying library, different ergonomics. The CLI gives you full programmatic control — custom distributions, cross-field logic, any output format. The browser tool is faster to set up, doesn't require Node installed, and produces a visual schema a teammate can regenerate without touching code.

Can I save my schema and reuse it next sprint?

Saving schemas is a Pro feature (up to 20 stored in IndexedDB). On the free tier, keep a copy of your field list in your repo — a short markdown file next to your test fixtures works fine and survives browser cache clears.