Mexican Test Data Generator
Generate fictitious RFC, CURP, CLABE and NSS with correct check digits to seed development environments and tests. Export to JSON, CSV or SQL. No server involved.
| First name | Paternal surname | Maternal surname | RFC | CURP | CLABE |
|---|
Everything is generated in your browser; nothing is sent to any server.
Fictitious data. The IDs satisfy the official format and check digit, but they do not belong to any real person or company and are not registered with the SAT, RENAPO, IMSS or Banxico. Use them for testing only.
What this tool does
It generates fictitious records for Mexican people or companies with RFC, CURP, CLABE and NSS that pass check-digit validation. You choose how many records you want and which fields to include, then export as a table, JSON, CSV or ready-to-paste SQL INSERT statements for a seeder.
It is built for the usual jobs: seeding a development environment, assembling test fixtures, or preparing a demo without copying the production database.
Why hand-typing the IDs does not work
Because the check digit will stop you. As soon as your form, your CSV import or your test suite verifies the RFC or the CLABE, an AAAA010101AAA typed on the fly fails and blocks you. The IDs here are computed with the same algorithm the authorities use, so they clear validation just like a real one.
And one detail matters more than it seems: the RFC and CURP within a record are consistent with each other. Both derive from the same name, surnames and date, so they share the four leading letters and the six date digits. If you generate each ID separately with two different tools, any logic that cross-checks them will report a false failure.
What it generates
People: first name and surnames, sex, date of birth, individual RFC, CURP, NSS, CLABE with a real bank from the Banxico catalogue, state, postal code, phone and email.
Companies: legal name, company RFC, incorporation date, CLABE, bank and postal code.
There are four output formats:
- Table to review at a glance.
- JSON for fixtures or API mocks.
- CSV to import into a spreadsheet or a database.
- SQL with
INSERT INTOand the table name already filled in.
The limits, stated plainly
The data is synthetic. It does not correspond to any real person or company, and it is not registered with the SAT, RENAPO, IMSS or any bank.
One clarification about the RFC: the first two positions of the homoclave are computed by the SAT with its own procedure from the full name, and here they are generated at random. What is computed correctly is the final check digit, which is what validations actually test. The resulting RFC is structurally valid, but it is not the one the SAT would issue for that name. For testing that is irrelevant; for a real filing it is useless.
Use it for development and tests. Never for invoicing with tax effects or for real filings.
A good practice, while we are here
Copying the production database into a test environment is convenient and is exactly what data-protection rules ask you not to do: you multiply copies of personal data across environments with weaker controls. Generating synthetic data that passes your validations is the recommended alternative, and this tool exists so that it costs no more effort than the easy route.
Related tools
- Mexican ID validator — RFC, CURP, CLABE, NSS — check any ID this tool produces.
- Mock data generator — the generic version, without Mexican IDs.
- CFDI 4.0 XML viewer — to inspect the invoices your test environment issues.
Frequently asked questions
Is the generated data from real people?
No. Names are randomly combined from common lists and the IDs are built with the public formatting rules, but they do not correspond to any existing person or company and are not registered with the SAT, RENAPO, IMSS or any bank. This is synthetic data meant to fill a development database without using real customer information — which is exactly what you should not be doing.
So why are they useful if they are made up?
Because they pass validation. If your form, your CSV import or your test suite checks the RFC or CLABE check digit, a hand-typed value will fail and block you. These IDs are computed with the same algorithm the authorities use, so they clear format validation just like a real one. That lets you exercise the happy path without touching anyone's personal data.
Are the RFC and CURP in one record consistent with each other?
Yes. Both derive from the same name, surnames and date of birth, so they share the four leading letters and the six date digits, exactly as they would in reality. This matters if you are testing logic that cross-checks the two IDs: with separately generated data that check would fail without any real bug in your code.
Is the homoclave the one the SAT would assign?
No, and it is worth being clear about it. The first two positions of the homoclave are computed by the SAT with its own procedure from the full name, and here they are generated at random. What is computed correctly is the final check digit, which is what validations actually test. In other words: the RFC is structurally valid, but it is not the RFC the SAT would issue for that name.
Can I export the data to my database?
Yes. Besides the table view you can export to JSON, to CSV or straight to SQL INSERT statements with the table name already filled in, ready to paste into a seeder or a migration. You pick which fields to include before exporting, so you do not drag along columns you never use.
Is it legal to use made-up RFCs or CURPs?
For development and internal testing, yes: they are strings that satisfy a format, not impersonation. What you must not do is use them in real filings, in invoicing with tax effects, or to register someone with an authority. Conversely, seeding your test environments with synthetic data instead of copying the production database is precisely the recommended data-protection practice.
Reviews & ratings
No reviews yet. Be the first to leave one!
Related tools
Others from the catalogue that pair well with this one.