Como validar CPF, CNPJ e RG no seu sistema

Validar documentos brasileiros corretamente é uma das tarefas mais comuns — e mais problemáticas — no desenvolvimento de sistemas nacionais. Formulários de cadastro, fluxos de checkout, emissão de notas fiscais: todos dependem de uma validação confiável. Este guia cobre os algoritmos por trás de CPF, CNPJ e RG, além das principais armadilhas que programadores enfrentam.

Validação de CPF em JavaScript

A validação do CPF exige três verificações: rejeitar strings com todos os dígitos iguais, verificar o primeiro dígito verificador com Módulo 11 e verificar o segundo dígito verificador. Uma implementação minimalista e correta em JavaScript pode ser escrita em menos de 20 linhas, mas é fácil errar nos edge cases.

A armadilha mais comum é esquecer de rejeitar CPFs como 000.000.000-00 ou 111.111.111-11. Eles passam no algoritmo matemático mas são bloqueados pela Receita Federal. Sempre adicione essa verificação explícita antes de rodar o Módulo 11.

Validação de CNPJ: diferenças para o CPF

O CNPJ usa o mesmo Módulo 11, mas com pesos diferentes. Além disso, o comprimento é 14 dígitos (contra 11 do CPF) e a regra de 'todos os dígitos iguais inválidos' também se aplica. Uma confusão frequente é usar os pesos do CPF ao implementar o CNPJ — isso gera validações erradas silenciosamente, aceitando CNPJs inválidos.

Validação de RG: por que é tão difícil

Diferente do CPF e CNPJ, o RG não tem um único padrão nacional. Cada estado brasileiro tem seu próprio formato, órgão emissor e algoritmo de verificação. O SSP-SP usa Módulo 11; outros estados usam Módulo 10 ou não têm dígito verificador. Isso torna a validação completa do RG extremamente complexa.

A abordagem mais pragmática para sistemas nacionais é validar apenas o formato (presença de dígitos e separadores esperados) sem tentar validar o dígito verificador, a menos que você saiba exatamente de qual estado o RG vem. Forçar validação matemática em RGs de estados que não usam esse algoritmo resultará em falsos negativos.

Validação no front-end vs back-end

Uma dúvida comum é onde colocar a validação. A resposta correta é: nos dois lugares. No front-end, a validação melhora a experiência do usuário, dando feedback instantâneo antes do envio do formulário. No back-end, ela é obrigatória por segurança — nunca confie em dados vindos do cliente sem revalidar no servidor.

Bibliotecas confiáveis para Node.js e Python

Para Node.js, a biblioteca `cpf-cnpj-validator` é amplamente usada e bem mantida. Para Python, `validate-docbr` cobre CPF, CNPJ, RG, CNH, título eleitoral e outros documentos brasileiros. Usar uma biblioteca testada pela comunidade é preferível a implementar do zero, pois ela já cobre edge cases documentados ao longo de anos.

Armadilhas comuns na validação

• Remover a formatação antes de validar: sempre limpe pontos, hífens e barras antes de rodar o algoritmo.
• Aceitar CPF/CNPJ com comprimento incorreto após limpeza: sempre verifique se tem exatamente 11 ou 14 caracteres numéricos.
• Não rejeitar sequências de dígitos iguais: 000.000.000-00, 111.111.111-11... até 999.999.999-99 são todos inválidos.
• Confundir validação matemática com consulta na Receita Federal: um CPF pode ser válido algoritmicamente mas inexistente ou cancelado.
• Esquecer o CNPJ alfanumérico (a partir de 2026): sistemas que só aceitam dígitos precisarão de atualização.

Validação de máscara: onde o usuário escorrega

Boa parte dos 'CPFs inválidos' que chegam ao back-end não são fraude — são problemas de máscara no front-end. O usuário cola um CPF com espaço no fim, a máscara não trata o paste, ou o teclado do celular insere um caractere invisível. A regra de ouro é normalizar agressivamente antes de validar: remova tudo que não for dígito com algo como `valor.replace(/\D/g, '')` e só então confira o comprimento e o dígito verificador. Validar a string crua, com pontuação, é receita para falsos negativos.

Onde colocar a mensagem de erro

Validação não é só lógica, é experiência. Um campo de CPF que só acusa erro depois que o usuário clica em 'Enviar' frustra; um que valida em tempo real, mas grita 'inválido' enquanto a pessoa ainda está digitando o terceiro dígito, irrita ainda mais. O equilíbrio é validar quando o campo perde o foco (evento blur) ou quando o comprimento esperado é atingido — e deixar claro se o erro é de formato (faltam dígitos) ou de dígito verificador (o número não fecha).

Performance: valide antes de consultar

Quando o fluxo envolve uma consulta externa (situação na Receita, CEP nos Correios, situação cadastral do CNPJ), a validação local do dígito verificador é a primeira linha de defesa. Ela custa microssegundos e elimina chamadas desnecessárias a APIs lentas ou tarifadas. A arquitetura ideal é: normaliza → valida o DV localmente → só os que passam seguem para a consulta externa. Isso reduz drasticamente o volume de requisições e melhora o tempo de resposta percebido.

Testando sua implementação

Para garantir que sua validação está correta, use nosso validador de CPF e validador de CNPJ para testar casos limite. Você também pode usar nossos geradores para obter lotes de números válidos e inválidos para seus testes automatizados — sem precisar usar dados reais de nenhuma pessoa ou empresa.

Perguntas frequentes

Devo guardar o CPF com ou sem pontuação no banco?

Sem pontuação — apenas os 11 dígitos. Isso evita duplicidade (o mesmo CPF com e sem máscara seria visto como dois) e simplifica buscas e índices. A pontuação é uma preocupação de apresentação, aplicada só na exibição.

Validar no front-end dispensa validar no back-end?

Nunca. A validação de front-end é conveniência para o usuário, mas pode ser burlada (basta desabilitar o JavaScript ou chamar a API direto). A validação de back-end é a que garante a integridade — sempre revalide no servidor.