Generate and Secure Test Data

Generate realistic synthetic profiles for your test environment

Use the Fake Person Generator to create realistic fake user profiles — names, email addresses, phone numbers, physical addresses, dates of birth, and other PII fields — that are structurally valid but refer to no real individual. Realistic test data is important because: (a) validation rules that accept real-looking emails, phone formats (including Indian mobile formats: +91 9XXXXXXXXX), and address structures will work correctly, (b) UI rendering that depends on string lengths (long names wrapping, short initials fitting avatars) behaves as in production, and (c) QA testers can run through realistic user journeys without confusion. Generate enough records to cover edge cases: very long names, international characters, names with apostrophes, email addresses with subdomains, phone numbers in different country formats.

Tip: Generate a 10–20% overage of records — you'll discard some in Step 2 when anonymising, and having extras avoids regenerating mid-workflow.

Anonymise any real PII fields that slipped into the dataset

Even when you intend to use only fake data, real PII can enter test environments through: copying a production database export, using a seed file from a real customer interaction, or copy-pasting a real API response as a test fixture. Use the Data Anonymizer to mask or replace any real names, email addresses, phone numbers, national IDs (Aadhaar, PAN, SSN), passport numbers, financial account numbers, IP addresses, and physical addresses found in your dataset. Anonymisation replaces real values with realistic-looking synthetic equivalents that preserve format validity — a real phone number becomes a fake phone number in the same format, not just '***'. This is different from redaction (replacing with asterisks) — anonymised data still passes validation rules and produces realistic API responses.

Tip: Run anonymisation on any dataset that originated from a production system, even if you believe it was already cleaned — this step is a safety net, not a primary control.

Scan the dataset for accidentally included credentials and secrets

After generating and anonymising PII, use the Secret Scanner to scan your test dataset for a different category of sensitive data: credentials and secrets. These include: API keys (AWS, GCP, Stripe, Twilio, SendGrid format patterns), JWTs, OAuth tokens, private keys (RSA, EC, PGP headers), database connection strings with embedded passwords, .env variable patterns, and hardcoded passwords. Test datasets accumulate secrets because developers copy real API responses (which sometimes include tokens in response headers or bodies), copy fixture files from production debugging sessions, or paste Postman collections that contain real credentials. The Secret Scanner uses pattern matching to flag these before they reach version control or shared staging environments where they could be exposed.

Tip: Also scan your fixture files and seed data scripts in version control — secrets committed to git remain in history even after deletion from the working tree.

Format and validate the final clean dataset before export

After completing Steps 1–3, you have a clean, PII-free, secret-free dataset. Use the JSON Formatter & Validator to format the final JSON output and confirm it is syntactically valid before deploying it to your staging environment or committing it as a test fixture. The formatter will surface: malformed JSON from incomplete anonymisation (a field replacement that broke the JSON structure), unclosed arrays or objects, duplicate keys (which some parsers accept but cause non-deterministic behaviour), and encoding issues with Unicode characters in names and addresses. Validate that the schema matches your expected structure — field names, data types, nesting depth, and array lengths should match your production data model. A valid JSON structure is the contract between your test data and your application.

Tip: Use the JSON Formatter's prettify mode to visually scan the structure and confirm field coverage before using the minified version for production fixture files.