Issue
Sign In
StepCodex FeaturedStepCodex Reviews
Notion Docs

Bulk generate test data. Free online tool, no login, no sign-up.

LocalPersonal data security

Loading Tool Engine

Usage Guide & Tech FAQ

Usage Guide

  1. Describe the target shape via JSON Schema, TS samples, or example JSON—specificity improves inference.
  2. Declare constraints (email, uuid, enums, min/max); bare `string` fields yield meaningless filler.
  3. Generate a tiny batch first (e.g., n=3) to verify empty arrays, nullables, and deep nesting.
  4. For snapshot tests, fix the RNG seed or disable randomness if available to avoid flaky CI.
  5. Feed outputs directly into API mocks (MSW, json-server) as response bodies.
  6. When synthesizing PII-like fields, use obviously fake ranges/watermarks to prevent mistaken real data.
  7. For load tests, chunk generation/stream writes instead of stringifying giant arrays at once.
  8. Guide locale/timezone fields with explicit samples rather than defaults.
  9. Validate exported JSON against schemas to ensure required fields/types hold.
  10. Tear down mock accounts after integration tests so passwords never drift into prod configs.
  11. Read the title and description first to confirm this utility matches your task (avoid using the wrong tool and misinterpreting output).
  12. Paste or type input in the editor; if a sample/template is provided, load it first to learn the expected output shape.

Related Tech Knowledge

  • Generators infer from names/types (`email`, `createdAt`); ambiguous names misclassify fields.
  • Random distributions ≠ real-world stats—not suitable for ML training or precise perf models.
  • Faker upgrades change sample shapes—pin versions for golden tests.
  • Cycles/deep recursion need schema caps to avoid stack overflows or tab crashes.
  • Unique constraints may collide under randomness—increase cardinality or dedupe post-process.
  • Regex-backed fields need engine support; complex patterns may degrade to arbitrary strings.
  • Separate OpenAPI “documentation examples” from “test data” responsibilities.
  • Security/isolation: never let mock payloads feed production telemetry—gate via env flags.
  • Browser generation is single-threaded; huge counts belong in Node/CLI tools.
  • Compliance: don’t seed mocks from real user rows; synthetic data still needs minimization discipline.
  • Core parsing and computation run in your browser; by default your raw business payload is not persisted to this site’s servers (see on-page privacy notes).
  • The pipeline is typically: read input → parse (lexical/syntactic/structured) → transform → render; failures aim to be diagnosable.