Formatando números de telefone brasileiro corretamente
A maior parte dos formulários e sistemas brasileiros pede que o número de telefone esteja no formato xx xxxxxxxxx, com dois dígitos para o DDD e oito para o número. Parece simples, mas é onde muita coisa quebra na prática. Vou explicar como fazer isso funcionar sem dor de cabeça.
Por que o telefone precisa estar no formato xx xxxxxxxxx
O formato com DDD junto ao número existe porque o Brasil usa discagem por composta universal desde os anos 90. Quando você marca um número para qualquer operadora, precisa digitar o DDD antes. Isso virou padrão nos bancos, em plataformas de login com OTP e em integrações de API. Quem constrói formulários ou rotinas de validação precisa respeitar esse padrão, senão o número cai como inválido do outro lado. O que a maioria dos tutoriais não explica é que o "x" representa um dígito, não um espaço. O formato correto é dois dígitos juntos, um espaço, oito dígitos juntos. Nada de parênteses, nada de traço. A entrada xx xxxxxxxxx quer exatamente doze caracteres numéricos mais um espaço no meio. Dezessete caracteres no total, se contar o espaço.
Como formatar na prática
O método mais direto é capturar o número cru, remover qualquer caractere que não seja dígito, verificar o tamanho e reposicionar. Se o número vier com o 55 do código do país na frente, remove os dois primeiros dígitos primeiro. Depois verifica se sobram onze dígitos — o nono dígito tem que ser 9 para celulares e 0, 1, 2, 3, 4, 5, 6, 7, 8 para fixos. Se não tiver esse nono dígito, o número está incompleto e não deve ser processado. Em JavaScript, uma função assim resolve a maior parte dos casos:
function formatarTelefone(valor) { var limpo = valor.replace(/\D/g, ''); if (limpo.length === 13 && limpo.startsWith('55')) { limpo = limpo.substring(2); } if (limpo.length !== 11) return null; return limpo.substring(0, 2) + ' ' + limpo.substring(2); } Isso devolve algo como 11 987654321, que já é o formato pedindo. Para fixos, o nono dígito é geralmente 0, então o resultado seria 21 34567890. A diferença é mínima na prática, já que a maioria dos sistemas exige o nove para ambos os tipos.
No Excel ou planilhas, a coisa fica mais feia porque não tem regex nativa. Uma fórmula funciona assim: =ESQUERDA(A1;2)&" "&SE(LONGO(A1)=11;MEIO(A1;3;8);SE(LONGO(A1)=13;MEIO(A1;5;8);"inválido")). Claro, isso pressupõe que a célula A1 já tenha só dígitos. Se vier com parênteses e traços, precisa de uma camada extra deLimpar = Substituir(Substituir(Substituir(Valor;",","");"(";"");")";""). Em Python, o pacote libphonenumber do Google resolve tudo sem você escrever uma linha de lógica. A instalação é pip install phonenumbers e a conversão é direta: phone = phonenumbers.parse(valor, 'BR'); phonenumbers.format_number(phone, phonenumbers.PhoneNumberFormat.NATIONAL). O resultado já sai no padrão brasileiro com DDD e espaço. O problema é que esse pacote não vem instalado por padrão e aumenta o tamanho do deploy em uns 4 megabytes. Vale a pena se você processa muitos números. Não vale se é um script que roda uma vez.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O problema que eu encontrei na vida real
Num projeto de integração com APIs de pagamento, precisei validar milhares de números de clientes para ativação de SMS de Two-Factor. A maior parte estava no formato errado porque os agentes de vendas copiam e colam de planilhas antigas. Um sistema externo exigia o formato xx xxxxxxxxx estrito, então minha rotina de limpeza tinha que funcionar mesmo com números sujos. O caso que me pegou foi um número que vinha como (11)98765-4321. A remoção dos não dígitos deu 11987654321, que tem onze dígitos e começa com 11. Até aí tudo certo. O problema era que o sistema de destino recusava números que começavam com 11 se o nono dígito não fosse 9. Na época achei que fosse bug do API, mas era só um cliente com número antigo de celular que ainda usava a sequência antiga de oito dígitos sem o nove indicador. A solução foi fazer uma validação prévia usando a base de dados da Anatel para verificar se o DDD 11 já cobria aquele prefixo com nove ou sem nove. O workaround que funcinou foi aceitar o número como estava e adicionar o nove automaticamente só quando o DDD era de região metropolitana e o nono dígito não era 9. Isso reduziu as recusas em cerca de oitenta por cento.
Detalhes que iniciantes ignoram
O primeiro erro comum é confundir DDd com área de operação. O DDD define a região geográfica, não a operadora. DDD 11 é São Paulo, DDD 21 é Rio de Janeiro, DDD 41 é Curitiba. Mas alguns DDDs são móveis em todas as regiões, como o 41 que hoje em dia pode ser tanto fixo quanto celular. Isso significa que confiar só no DDD para saber se é celular não funciona mais. O nono dígito é o indicativo confiável, mas nem sempre está presente em todas as bases. O segundo erro é tratar números com 55 na frente como válidos. O 55 é o código de discagem internacional do Brasil. Quando um número vem de exportação de CRM ou de alguma API estrangeira, ele quase sempre vem com 55 na cabeça. Se você formatar isso como xx xxxxxxxxx direto, vai virar 55 xxxxxxxxx1, que é um número com treze dígitos e totalmente inválido. Sempre remova o 55 antes de formatar, exceto se o sistema de destino pedir explicitamente o prefixo internacional.
Um terceiro ponto que poucas pessoas levam em conta: números de aplicativos de voz como WhatsApp Business ou serviços VoIP muitas vezes não têm DDD geográfico real. Eles usam DDDs fictícios ou DDDs de operadoras virtual. O formato xx xxxxxxxxx continua válido, mas a geolocalização do número não faz sentido. Se o seu sistema usa o DDD para direcionar atendimento regional, isso vai falhar nesses casos.
Limitações e quando o formato não serve
O formato xx xxxxxxxxx não funciona para números fixos antigos que ainda usam apenas sete dígitos depois do DDD. Esses números existem principalmente em capitais grandes e em sistemas legados. Se o seu formulário aceita qualquer telefone brasileiro, você vai ter que lidar com versões de oito e sete dígitos após o DDD. O ideal é permitir a entrada nos dois formatos e normalizar para o de oito dígitos adicionando um zero à esquerda se necessário, mas isso depende de cada sistema. Também não serve para ramais. Se você precisa registrar o número completo de uma empresa com ramal, o formato(xx xxxxxxxxx) só pega o número principal. A solução comum é ter um campo separado para ramal ou concatenar com traço, como 11 987654321 ram 102. Nenhum sistema padrão de validação de telefone reconhece essa estrutura, então a validação tem que ser personalizada.
Alternativas ao formato rígido
Se você está construindo algo do zero e não tem restrição de legado, considere aceitar o número em qualquer formato e converter internamente. O padrão E.164, que é +5511987654321, é o mais seguro para armazenamento e processamento. A exibição para o usuário pode ser formatada como xx xxxxxxxxx quando necessário, mas o que vai para o banco de dados deve ser E.164. Isso evita duplicação, facilita a busca e elimina erros de formatação. A conversão de E.164 para o formato legível é trivial e pode ser feita na hora de exibir. Se o sistema de destino realmente exige xx xxxxxxxxx e não aceita E.164, a única saída é formatar na hora do envio. Não adianta tentar armazenar no formato legível e converter depois, porque aí você perde informação sobre o DDD ou introduz erro na conversão. Armazene E.164, formate no momento da requisição. Esse é o jeito que funciona sem quebrar.
