Gerador de CPF

O CPF (Cadastro de Pessoa Física) é composto por 11 dígitos. Os nove primeiros formam a base numérica; o nono dígito, chamado de dígito regional, indica a região fiscal de emissão original. Os dois últimos são os dígitos verificadores, calculados a partir dos anteriores.

Cálculo do 1º dígito verificador

Multiplica-se cada um dos 9 primeiros dígitos pelos pesos 10, 9, 8, 7, 6, 5, 4, 3, 2 respectivamente. Soma-se os produtos e aplica-se o resto da divisão por 11. Se o resto for menor que 2, o dígito é 0; caso contrário, é 11 − resto.

Cálculo do 2º dígito verificador

O mesmo processo é repetido usando os 10 primeiros dígitos (incluindo o 1º verificador recém-calculado) e os pesos 11, 10, 9, 8, 7, 6, 5, 4, 3, 2. A mesma regra de resto se aplica.

Mapeamento do 9º dígito por região fiscal

Esse mapeamento não é mais mandatório para novos cadastros, mas permanece relevante para sistemas legados e para gerar CPFs de teste vinculados a uma UF específica.

Utilizar CPFs reais de clientes em ambientes de desenvolvimento e homologação é uma prática que viola diretamente a Lei Geral de Proteção de Dados (Lei 13.709/2018) e expõe a empresa a sanções da ANPD (Autoridade Nacional de Proteção de Dados). CPFs sintéticos resolvem esse problema.

Casos de uso comuns

• Testes de formulários — validar campos de CPF em cadastros, checkouts e KYC sem comprometer dados reais.
• Integração com APIs — testar endpoints que recebem CPF como parâmetro (ex.: Receita Federal, bureaus de crédito em sandbox).
• Testes automatizados (QA) — alimentar suítes de testes E2E com CPFs que passam em validações sem acionar bases de dados reais.
• Seed de banco de dados — popular ambientes de staging com dados realistas para demonstrações e carga de performance.
• Treinamento de modelos de ML — gerar datasets sintéticos que preservam a estrutura do dado real sem expor PII (Personally Identifiable Information).

Diferença entre CPF válido e CPF real

Um CPF é matematicamente válido quando seus dígitos verificadores estão corretos. Isso não significa que ele esteja cadastrado na base da Receita Federal. Os números gerados por esta ferramenta passam em qualquer biblioteca de validação (cpf-cnpj-validator, cpf.js, validate-br etc.), mas uma consulta direta à Receita confirmará que não há cadastro associado.

A LGPD estabelece que dados pessoais somente podem ser tratados com base em uma das hipóteses legais do Art. 7º. Em ambientes de desenvolvimento, nenhuma dessas hipóteses se aplica ao uso de dados reais de titulares. O uso de dados sintéticos elimina essa dependência.

Princípios da LGPD atendidos com dados fictícios

• Finalidade (Art. 6º, I) — dados de teste têm propósito claro e limitado ao desenvolvimento de software.
• Necessidade (Art. 6º, III) — apenas o mínimo necessário é utilizado; dados fictícios não envolvem o titular real.
• Segurança (Art. 6º, VII) — um vazamento de dados de teste não compromete nenhum titular real.
• Não discriminação (Art. 6º, IX) — dados sintéticos não permitem perfis comportamentais sobre pessoas reais.

Esta ferramenta e a LGPD

O Gerador de CPF processa tudo no próprio navegador do usuário (client-side). Nenhum número gerado é transmitido a servidores, registrado em banco de dados ou associado a qualquer identidade. Não coletamos dados pessoais dos usuários além dos registros de navegação padrão (GA4 com IP anonimizado). Para mais detalhes, consulte nossa Política de Privacidade.

A lógica de validação é simples o suficiente para ser implementada manualmente, sem bibliotecas externas. Abaixo estão implementações de referência nas linguagens mais utilizadas.

JavaScript / TypeScript

function isValidCpf(cpf: string): boolean {
  const digits = cpf.replace(/\D/g, "");
  if (digits.length !== 11) return false;
  if (/^(\d)\1{10}$/.test(digits)) return false;

  const calc = (len: number) => {
    const sum = digits
      .slice(0, len)
      .split("")
      .reduce((acc, d, i) => acc + Number(d) * (len + 1 - i), 0);
    const rem = (sum * 10) % 11;
    return rem === 10 || rem === 11 ? 0 : rem;
  };

  return (
    calc(9) === Number(digits[9]) &&
    calc(10) === Number(digits[10])
  );
}

Python

import re

def is_valid_cpf(cpf: str) -> bool:
    digits = re.sub(r"\D", "", cpf)
    if len(digits) != 11 or len(set(digits)) == 1:
        return False

    def calc(length: int) -> int:
        total = sum(int(digits[i]) * (length + 1 - i) for i in range(length))
        rem = (total * 10) % 11
        return 0 if rem >= 10 else rem

    return calc(9) == int(digits[9]) and calc(10) == int(digits[10])

Quer ver implementações mais avançadas, incluindo geração em lote, integração com Faker.js e estratégias de seed para banco de dados? Acesse nosso blog técnico →

Qualquer profissional que precise de CPFs matematicamente válidos sem comprometer dados reais vai se beneficiar desta ferramenta. Os casos mais frequentes que observamos:

• Desenvolvedores back-end que precisam de CPFs para popular seeders, migrations e fixtures em projetos com Node.js, Java, Python, PHP, Go e outras stacks.
• QA Engineers e testadores que constroem suítes de testes E2E com Cypress, Playwright ou Selenium e precisam de CPFs que passem nas validações de formulários sem acionar bases de produção.
• Desenvolvedores front-end que implementam máscaras, validadores e componentes de input de CPF e precisam de dados de teste imediatos.
• Engenheiros de dados que precisam gerar datasets sintéticos realistas para pipelines de ETL, data warehouses e treinamento de modelos.
• Estudantes e professores de cursos de programação, análise de sistemas e segurança da informação que ensinam validação de documentos brasileiros.
• Equipes de DevOps e SRE que configuram ambientes de staging e homologação com dados sintéticos alinhados à LGPD.

Se você precisa apenas "testar um site aleatório", esta ferramenta também funciona — mas foi projetada para ir além disso, com geração em lote, filtro por estado e integração via API REST.

Ao longo de projetos com cadastro de usuários, financeiras, fintechs e plataformas de e-commerce, o fluxo de dados de teste com CPF aparece em cenários muito previsíveis. Aqui estão os mais comuns:

1. Testes de validação em formulários de cadastro

Toda aplicação que recebe CPF precisa garantir que o campo rejeita entradas inválidas e aceita entradas válidas. Com CPFs fictícios matematicamente corretos, é possível cobrir os dois caminhos sem tocar em dados de titulares reais. Um CPF inválido (ex.: 111.111.111-11) e um CPF gerado aqui cobrem o happy path e o sad path do formulário.

2. Seed de banco de dados em staging

Ambientes de homologação precisam de dados realistas para reproduzir comportamentos de produção. Gerar 500 CPFs de uma vez e exportar para um script SQL ou um arquivo JSON é a forma mais rápida de popular uma tabela de usuários fictícios sem violar a LGPD.

3. Integração com APIs de parceiros em sandbox

Bureaus de crédito, fintechs e gateways de pagamento geralmente oferecem ambientes sandbox que exigem CPFs válidos como parâmetro — mesmo para testes. CPFs fictícios gerados aqui passam na camada de validação de formato desses parceiros sem acionar consultas reais.

4. Fixtures em suítes de testes automatizados

Frameworks como Jest, Vitest, Pytest e JUnit permitem definir fixtures — conjuntos de dados pré-definidos reutilizados em múltiplos testes. Ter um conjunto de CPFs fictícios válidos (e alguns propositalmente inválidos) como constantes no repositório é uma prática comum em times de QA maduros.

5. Demonstrações de produto para clientes

Em demos ao vivo ou gravações de produto, nenhum dado real deve aparecer na tela. CPFs fictícios preenchem esses campos com aparência realista sem expor nenhum titular.

Empresas reguladas pelo Banco Central, pela ANPD ou por auditorias SOC 2 têm uma necessidade ainda mais crítica de separar dados reais de dados de teste. Os padrões que surgem nesses ambientes são consistentes:

Fintechs e bancos digitais

O fluxo de onboarding de fintechs é o cenário com maior densidade de uso de CPF. Validação de formato, consulta de bureaus, abertura de conta digital — cada etapa precisa ser testada com dados que se comportem como dados reais sem sê-lo. Times de engenharia mantêm bancos de CPFs sintéticos com centenas de entradas para cobrir perfis variados de usuário.

E-commerce e marketplaces

Plataformas de e-commerce coletam CPF no checkout para emissão de nota fiscal e validação antifraude. O pipeline de testes do checkout — desde o carrinho até o pagamento — depende de CPFs fictícios válidos que não acionem regras de antifraude de produção nos ambientes de sandbox dos gateways.

Healthtechs e operadoras de saúde

Sistemas de saúde trabalham com dados sensíveis sob regulamentação dupla: LGPD e resoluções do CFM/ANS. Usar CPFs sintéticos em sistemas de prontuário eletrônico e agendamento é uma exigência de conformidade, não apenas uma boa prática.

Empresas de logística e rastreamento

Sistemas de rastreamento de encomendas, verificação de identidade na entrega e gestão de destinatários precisam de CPFs nos registros de teste. A geração de CPFs por estado (via o 9º dígito) é especialmente útil para simular usuários de regiões geográficas específicas.

A forma como você usa CPFs fictícios nos seus testes diz muito sobre a maturidade do seu processo de QA. Algumas práticas que fazem diferença concreta:

Versionar os CPFs de teste no repositório

Defina um arquivo de fixtures (ex.: test/fixtures/cpfs.ts) com CPFs válidos e inválidos para uso em toda a suíte. Isso garante reprodutibilidade e evita que cada desenvolvedor gere os próprios dados localmente.

Cobrir os edge cases do algoritmo

Os casos especiais mais esquecidos em validadores de CPF:

• CPFs com todos os dígitos iguais (111.111.111-11) — inválidos por definição, mas estruturalmente formatados
• CPFs com máscara vs. sem máscara como entrada
• Entrada com espaços, pontos ou traços extras
• CPF com tamanho incorreto (10 ou 12 dígitos)
• Entrada nula ou vazia
• CPF com letras misturadas

Separar CPFs por estado para testes regionais

Se sua aplicação tem comportamento diferente por UF (ex.: alíquotas de ICMS, regras de entrega, cobertura de plano de saúde), use o filtro de estado desta ferramenta para gerar CPFs com o 9º dígito correspondente a cada região fiscal e cubra cada ramo do código com o estado correto.

Usar a API para geração dinâmica em testes

Em vez de CPFs fixos no código, você pode chamar a API REST gratuita no beforeEach dos seus testes para garantir CPFs únicos a cada execução e evitar colisões em banco de dados com unique constraints.

Essa distinção é frequentemente confundida e causa bugs em sistemas que tentam usar a validade matemática como prova de existência cadastral.

Analogia: é como a diferença entre um número de telefone com DDD e quantidade de dígitos corretos (formato válido) versus um número que realmente existe na operadora e está ativo (existente). Os CPFs gerados por esta ferramenta são válidos no primeiro sentido, nunca no segundo.

Por que isso importa na prática?

• Bibliotecas de validação (front-end e back-end) verificam apenas a validade matemática. CPFs gerados aqui passam nessas validações.
• Serviços de consulta da Receita Federal verificam a existência cadastral. CPFs fictícios retornarão "não encontrado" nessas consultas.
• Se sua aplicação consulta a Receita em produção, os testes com CPFs fictícios precisam mockar essa chamada externa.

Testes end-to-end que envolvem formulários com CPF são um dos cenários mais comuns em QA de aplicações brasileiras. Veja como integrar CPFs fictícios de forma limpa em cada framework.

Cypress — usando a API para gerar CPF dinâmico

// cypress/support/commands.ts
Cypress.Commands.add("getCpf", () => {
  return cy
    .request("https://geradordecpf.com.br/api/cpf")
    .its("body.cpf");
});

// cypress/e2e/cadastro.cy.ts
describe("Cadastro de usuário", () => {
  it("deve aceitar CPF válido no formulário", () => {
    cy.getCpf().then((cpf) => {
      cy.visit("/cadastro");
      cy.get('[data-testid="cpf-input"]').type(cpf);
      cy.get('[data-testid="submit"]').click();
      cy.get('[data-testid="success-message"]').should("be.visible");
    });
  });
});

Playwright — fixture com CPFs pré-gerados

// tests/fixtures/cpfs.ts
export const VALID_CPFS = [
  "529.982.247-25",
  "111.444.777-35",
  "803.247.930-56",
];
export const INVALID_CPFS = [
  "111.111.111-11",
  "000.000.000-00",
  "123.456.789-00",
];

// tests/cadastro.spec.ts
import { test, expect } from "@playwright/test";
import { VALID_CPFS, INVALID_CPFS } from "./fixtures/cpfs";

test.describe("Validação de CPF", () => {
  for (const cpf of VALID_CPFS) {
    test(`aceita CPF válido: ${cpf}`, async ({ page }) => {
      await page.goto("/cadastro");
      await page.fill('[data-testid="cpf-input"]', cpf);
      await page.click('[data-testid="submit"]');
      await expect(page.locator(".error-cpf")).not.toBeVisible();
    });
  }

  for (const cpf of INVALID_CPFS) {
    test(`rejeita CPF inválido: ${cpf}`, async ({ page }) => {
      await page.goto("/cadastro");
      await page.fill('[data-testid="cpf-input"]', cpf);
      await page.click('[data-testid="submit"]');
      await expect(page.locator(".error-cpf")).toBeVisible();
    });
  }
});

Para mais padrões de integração com testes automatizados, consulte nosso artigo Testes E2E com Playwright e formulários com CPF →

Abaixo estão CPFs de referência para uso em testes. Os CPFs válidos foram gerados pelo algoritmo oficial e passam em qualquer validador. Os inválidos cobrem os edge cases mais comuns que um validador robusto deve rejeitar.

CPFs válidos por região fiscal

CPFs inválidos para testes de rejeição

Para gerar sua própria massa de testes personalizada — com quantidade, estado e formato específicos — use a API REST ou o gerador acima com até 500 CPFs por operação.