Brazil's CPF — Cadastro de Pessoas Físicas — is the country's individual taxpayer ID. Eleven digits, two of them verifiers, one of them encoding the fiscal region where the document was first issued. Every adult in Brazil has one, every foreigner with local tax obligations has one, and every Brazilian web form eventually asks for one. This generator emits valid-format CPFs for tests and seed data only — they pass the módulo 11 check but do not exist in Receita Federal's database.
What CPF actually is
The CPF was created in 1965 by Lei nº 4.862 under the original name Registro de Pessoas Físicas, then renamed and stabilised by Decreto-Lei nº 401 of December 30, 1968. Receita Federal — Brazil's federal tax authority — administers the registry. Every entry in the database is an eleven-digit number, conventionally formatted as XXX.XXX.XXX-XX with dots separating the first nine digits into three groups of three and a dash before the two final verifier digits.
Since Lei nº 14.534/2023, the CPF is also the single national registration number — replacing the older RG state IDs in the new Carteira de Identidade Nacional (CIN). Brazilians have until February 2032 to migrate, but the CPF format itself is unchanged.
CPF anatomy: nine plus two
The first nine digits are the base. The ninth digit doubles as the fiscal region marker (more on that below). The tenth and eleventh digits are checksums computed from the previous nine and ten digits respectively, using a weighted módulo 11 scheme.
The checksums catch typos — transpose two digits in the base and the verifiers will almost certainly stop matching. They do not catch deliberate forgery, since anyone who knows the algorithm can mint a valid-looking CPF. That is exactly what this generator does, and exactly why every output ships with a test-only disclaimer.
The módulo 11 verifier algorithm
To compute verifier digit d₁₀, multiply each of the nine base digits by weights [10, 9, 8, 7, 6, 5, 4, 3, 2] in order, sum the products, take the result modulo 11. If the modulus is 0 or 1, the verifier is 0 (otherwise it is 11 - mod). For d₁₁, repeat with the now-ten known digits (base + d₁₀) and weights [11, 10, 9, 8, 7, 6, 5, 4, 3, 2].
The choice of 11 is not arbitrary: 11 is prime, so the remainder space (0..10) does not collapse under multiplication, which gives the scheme stronger error-detection properties than a modulo-10 alternative would. The same weighted-modulo-11 family is reused for CNPJ (corporate IDs) and other Brazilian identifier formats.
One quirk: a CPF whose eleven digits are all identical — 00000000000, 11111111111, …, 99999999999 — happens to satisfy the checksum math, but Receita Federal explicitly excludes them. A valid-looking CPF that fails this rule is the canonical example of an algorithm that passes naïve implementations and gets rejected at the gate. This generator filters them out.
In production, Brazilian financial institutions and government portals stack two checks. The format checksum — what this generator emits correctly — is the cheap first pass that catches typos and most fake submissions before they hit the backend. The second pass is a database lookup against the Receita Federal registry, available only through regulated KYC providers (Serasa, SPC, Bacen-licensed bureaus) operating under formal data-sharing contracts. There is no public lookup API. Knowing this distinction matters: a system that checks only the first layer is vulnerable to anyone with a pocket calculator, while a system that depends solely on the second layer is paying for an external dependency that could go down.
Fiscal region encoded in the 9th digit
Receita Federal divides Brazil into ten fiscal regions for administrative purposes, and the 9th digit (index 8) of a CPF encodes the region where the holder first registered. The mapping is canonical and stable:
0— Rio Grande do Sul1— Distrito Federal, Goiás, Mato Grosso, Mato Grosso do Sul, Tocantins2— Acre, Amazonas, Amapá, Pará, Rondônia, Roraima3— Ceará, Maranhão, Piauí4— Alagoas, Paraíba, Pernambuco, Rio Grande do Norte5— Bahia, Sergipe6— Minas Gerais7— Espírito Santo, Rio de Janeiro8— São Paulo9— Paraná, Santa Catarina
The encoding is immutable. Someone who registered in Rio in 1985 and moved to Lisbon in 2010 still carries a CPF with 9th digit 7. For testing flows that depend on region — fraud heuristics, shipping geography, regional pricing — this generator lets you pin a specific region per CPF.
Test-only ethics: a generator is not a backdoor
Generating valid-format CPFs for QA fixtures, integration tests, and seed data is standard practice in Brazilian software development. Using a generated CPF to claim another person's identity, file a fake declaration, or pass KYC under false pretences is falsidade ideológica — Article 299 of the Brazilian Penal Code — punishable by one to five years in prison plus a fine when the document is public. That is the line. Receita Federal does not maintain a public CPF lookup API; if you need to verify a real CPF, the customer must consent and you must use a regulated KYC provider.
CPF and LGPD
Brazil's Lei Geral de Proteção de Dados (LGPD, Lei nº 13.709/2018) classifies CPF as dado pessoal — personal data — under Article 5, Section I. It is not formally sensitive data the way race, religion, or biometrics are, but the practical risk is high: a CPF is a strong identifier that links across financial, fiscal, and credit systems. Treat it like a primary key, not a throwaway. Hash or tokenise before logging; minimise where you can; never email it in clear.
This generator runs entirely in your browser. No CPF — generated or validated — is ever transmitted to a server. The implementation uses crypto.getRandomValues with rejection sampling for the base nine digits, the same Web Crypto primitive a modern browser uses for TLS key generation. Recent inputs (settings only — never the generated values) live in your local browser storage and can be cleared at any time.
Where this generator earns its keep
Three patterns dominate in practice. First, seeding a development database with fifty plausible-looking customers in one click — quantity selector, copy all, done. Second, validating a form that accepts both formatted and raw CPF input — paste, watch the live verdict, ship. Third, exercising a region-aware backend by forcing the 9th digit and confirming the right code path fires. All three avoid the common-but-illegal shortcut of using your own CPF in production tests.
A useful fourth pattern is stress-testing your validation layer with the all-same-digit edge cases. Paste 11111111111 into Validate mode and watch the disclaimer fire; if your downstream system accepts it, the bug is in your stack, not in Receita Federal's policy. Reproducing edge cases this way is considerably faster than waiting for them to surface in production support tickets.