Copying production data into a development environment is convenient and dangerous. Real names, emails and phone numbers spread to staging servers, laptops and log files, and any one of those leaking becomes a privacy incident. Testing against empty data, meanwhile, hides problems you would have caught.
This tool works in both directions. Define the columns you need and generate realistic fake rows, or paste a real CSV and apply per-column strategies — mask, hash, replace with fake values, shuffle within the column, or drop it entirely. Files are processed in the browser and never uploaded.
How to use
- Choose a mode — Generate mock data when you need a fresh dataset, anonymize CSV when you already have real data to sanitise.
- Generate — define the columns — Set column names and data types and pick a row count. The data locale controls whether names, addresses and phone numbers look Korean or Anglophone. Regenerate produces a fresh set of values.
- Anonymize — assign strategies — Paste or upload a CSV and the columns are detected, with a strategy suggested from each column's name: fake values for names, masking for emails, hashing for identifiers and card numbers. Override any of them.
- Review and download — Check the first ten rows in the preview, then export as CSV or JSON. The CSV includes a BOM so it opens correctly in Excel.
Frequently asked questions
Is my uploaded CSV sent to a server?
No. The file is read with the browser's File API, processed in memory, and the download is generated locally.
Given what this tool handles, that was the design requirement from the outset. Be aware that very large files (tens of megabytes) can exceed browser memory; at that scale a script is the better instrument.
Should I mask or hash?
They serve different purposes.
Masking hides part of the value while keeping its shape recognisable (minjun.kim@corp.co.kr → mi**********@corp.co.kr), which suits screenshots and UI display.
Hashing maps the same input to the same output every time, so you cannot recover the original but you can still tell whether two rows refer to the same person. That makes it useful as a join key or for aggregate analysis. Where the value space is small — dates of birth, for instance — a hash can be reversed by brute force, so add a secret salt.
Does anonymising here make me compliant with privacy law?
Not on its own. This is a practical aid, not a legal determination.
Even with individual columns obscured, combinations can re-identify people; the classic result is that gender, date of birth and postal code together identify a large share of a population. If you are handling regulated data, assess combination risk and confirm your approach with your privacy officer or counsel.
Concepts worth knowing
Pseudonymisation versus anonymisation
Pseudonymised data can be re-linked to an individual with additional information; anonymised data cannot be re-identified by any means. GDPR and most national privacy laws treat them very differently.
Pseudonymised data is still personal data and keeps its safeguarding obligations, though it may be processed for statistics and research under narrower conditions. Truly anonymous data falls outside the regime. Hashing here is closer to pseudonymisation because identity matching survives; replacing with fake values is closer to anonymisation.
Mock data with referential integrity
Realistic testing needs the relationships to survive: an orders table's user_id must exist in the users table for joins to work.
This tool focuses on a single table, so for a multi-table set, generate users first, take that ID list, and populate the orders table's user_id column from it. The shuffle strategy serves a related purpose — it preserves each column's distribution while breaking the link between columns within a row.
CSV pitfalls
CSV looks trivial and is not. Values containing commas or newlines must be quoted, and a literal quote is escaped by doubling it. Both parsing and generation here go through a library that implements those rules.