Sample Data Generator

Synthetic people for tests and demos

Software needs person-shaped records long before production users exist: forms, import pipelines, CRM sandboxes, and screenshot demos. The People family generates sample person data and exports it in common interchange formats so fixtures stay reproducible and free of real personal data.

Start with the person generator when you need names, addresses, and contact-style fields for a quick manual test, then switch to a structured export when a tool expects a file.

Why synthetic data matters

Real names, emails, and phone numbers from production logs create privacy and compliance risk when reused in tickets, screenshots, or public repos. Synthetic records let you exercise validation, sorting, and serialization without copying living people. They are still person-like: unique-looking emails, plausible addresses, and field shapes that resemble production schemas.

Treat every generated row as fictional. Do not present samples as real customers. Do not use generators to invent identities for fraud, impersonation, or account abuse.

Core generator vs format exporters

The family splits into a general generator and format-specific exporters that share the same domain idea—person records—but differ in serialization:

• Generator — create sample person records for interactive testing.
• JSON — formatted JSON array for APIs, Node scripts, and front-end mocks.
• XML — structured XML documents for legacy integrations and SOAP-era fixtures.
• CSV — comma-separated rows for spreadsheets and bulk import dry-runs.
• YAML — indentation-friendly documents for config-style fixtures and GitOps samples.

Choose the format your consumer already speaks. Converting by hand between formats is error-prone; regenerate in the target shape when field sets differ.

Typical schemas and fields

Person fixtures usually include a stable-looking identity surface: given name, family name, email, phone, postal address components, and sometimes birth date or locale hints. Exact fields depend on the subtool implementation. When you assert in tests, prefer checking structure (required keys, types, non-empty strings) over hard-coding a single generated name that may change across runs if randomness is involved.

For deterministic CI, pin seeds or store golden files when your stack supports that pattern. Browser generators are excellent for exploratory QA; committed fixtures are better for regression suites.

Format notes

JSON. Arrays of objects are the usual shape for REST mocks. Watch trailing commas (invalid in strict JSON) if you edit by hand after export.

CSV. Spreadsheets reinterpret encodings, leading zeros in postal codes, and formulas that start with =. Open imports as text when those fields matter. Quoting rules matter for commas inside address lines.

XML. Element names and nesting must match what your parser expects. Character encoding and entity escaping matter for names with accents.

YAML. Indentation is significant. Prefer JSON if a consumer is ambiguous about YAML 1.1 vs 1.2 quirks (yes/no, sexagesimal numbers).

When to use which subtool

Limitations and ethics

• Not identity verification. Generated documents are not government IDs, KYC proofs, or credit histories.
• Not exhaustive locales. Name and address realism varies; some locales may be underrepresented.
• Not production PII. Never mix generated rows with real customer extracts in the same file without clear labeling.
• Rate and volume. Browser tools are for modest fixture batches, not millions of rows for load tests—use dedicated data factories in code for that scale.
• Bias. Random name pools can over-represent certain cultures; diversify fixtures intentionally for inclusive QA.

Workflows that stay safe

1. Generate a small batch for the feature under test.
2. Export to the format your importer expects.
3. Label files sample- or fixture- in repositories.
4. Scrub screenshots so demo emails do not look like real support contacts.
5. Rotate or regenerate if a sample string accidentally matches a real person you know.

Pair People data with Text tools when you need to slugify display names or validate profile URLs, and with Random only when you need non-person randomness (dice, shuffles).

Related tooling

• Generator
• JSON export
• XML export
• CSV export
• YAML export

Summary

People tools invent fictional person records for testing and demos, then serialize them as JSON, XML, CSV, or YAML. Prefer synthetic fixtures over production PII, pick the exporter that matches your consumer, and keep ethics clear: samples are for software quality, not real-world identity claims.