Existe uma piada na comunidade de regex: “Escreva uma regex de validação de e-mail e você dará pesadelos aos engenheiros de QA.” Regex de e-mail na internet ou são curtas demais e perdem metade dos casos, ou são tão longas que parecem ransomware. Este post pula as brincadeiras e traz 7 padrões testados em produção — sem buscar rigor acadêmico, mas sim utilidade prática. Combine com o testador de regex do Piick e você pode observar e ajustar ao longo do caminho.

Por que não existe uma “regex universal”

A definição do formato de e-mail no padrão RFC 5322 tem centenas de linhas; um e-mail válido pode ser parecido com "user+tag"@sub.example.museum. Tentar cobrir todos os casos válidos com uma única regex significa escrever um “monstro de regex” de 200 caracteres que você não vai ousar tocar seis meses depois.

Princípio prático: use a versão simplificada que acerta 99% e deixe o backend enviar um e-mail de verificação para pegar o 1% restante. Não confie em regex de frontend para validação de e-mail — confie no servidor realmente enviando o e-mail.

As 7 melhores regex para cenários frequentes

Esses 7 padrões vêm todos de código em produção, cobrindo as necessidades mais comuns:

  1. E-mail [A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,} — versão simplificada, 99% dos e-mails passam
  2. URL https?:\/\/[^\s<>"']+ — do início http/https até espaço em branco ou aspas angulares
  3. Telefone (internacional) \+?[1-9]\d{1,14} — formato E.164, no máximo 15 dígitos
  4. Endereço IPv4 \b(?:25[0-5]|2[0-4]\d|[01]?\d?\d)(?:\.(?:25[0-5]|2[0-4]\d|[01]?\d?\d)){3}\b — estrito 0-255 segmento a segmento
  5. Data ISO \d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01]) — ano-mês-dia com checagem de faixa para mês e dia
  6. Cor hexadecimal #?([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})\b — aceita #fff e #FFFFFF
  7. Slug de URL [a-z0-9]+(?:-[a-z0-9]+)* — letras/dígitos com hífens, o formato comum de URL de artigos

O dropdown Common Patterns no testador de regex do Piick já tem esses 7 prontos — é só colar e usar, sem precisar digitá-los.

Teste e ajuste em tempo real com o Piick

Copiar a regex de outra pessoa tem uma armadilha: você não sabe o que cada parte significa. O painel Explain do Piick detalha a regex token a token, dizendo o que cada parêntese e quantificador faz:

  • Metacaracteres (\d, \w, \b) são rotulados como âncora / classe
  • Quantificadores (*, +, {2,5}) são rotulados como quantificador
  • Grupos e retrovisores são rotulados como grupo / backref

Fluxo de depuração: cole a regex → confira o detalhamento do Explain → cole o texto de teste → veja o destaque do match → edite uma linha → veja o efeito imediatamente. Sem recarregar a página; é só editar e rodar.

Dicas para manter sua própria biblioteca de padrões

3 hábitos que tornam as regex mais fáceis de manter:

  1. Grupos de captura nomeados em vez de numerados: (?<year>\d{4}) é mais legível que (\d{4}) — ao extrair dados depois, você não vai errar a contagem dos parênteses
  2. Quebre regex complexas em várias linhas com comentários: use new RegExp(\…`)` junto com variáveis de comentário para ainda entender seis meses depois
  3. Centralize tudo em um arquivo lib/regex.ts — não espalhe new RegExp(...) por todo lado; uma mudança não deveria significar procurar em 50 arquivos

Indo além: armazene as regex que seu projeto usa comumente como um objeto, com a chave sendo o nome e o valor sendo {pattern, flags, sample}. Cada novo membro do time consegue usar diretamente, sem copiar do zero. Essa é exatamente a ideia por trás dos 7 padrões comuns prontos no testador de regex do Piick — quanto maior a biblioteca de padrões, menos reinventar a roda.

Abra agora o testador de regex do Piick, clique no dropdown Common Patterns, escolha e-mail e cole um texto de teste para ver o casamento em ação.