Cinco expressões regulares que vale a pena memorizar

Regex é uma daquelas habilidades que todo dev aprende uma vez, erra na primeira versão em produção, e aí passa os próximos anos copiando de Stack Overflow. Este post é pra você memorizar as cinco que você vai usar de verdade.

Cinco padrões, cada um com a expressão exata, a explicação do que faz e um caso de uso real.

E-mail

^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$

Valida o formato básico de e-mail. Não tenta seguir o RFC 5321 inteiro (que permitiria "user name"@example.com) — esse nível de fidelidade raramente faz sentido em formulários.

O que cada parte faz: [a-zA-Z0-9._%+\-]+ captura o local part (tudo antes do @). [a-zA-Z0-9.\-]+ captura o domínio. \.[a-zA-Z]{2,}$ exige um TLD de pelo menos 2 chars.

Limitação conhecida: não valida existência do domínio. Use isso como primeira barreira, não como única validação.

Slug de URL

^[a-z0-9]+(?:-[a-z0-9]+)*$

Valida slugs no formato palavra-composta-assim. Começa e termina com alfanumérico, hífens apenas entre segmentos. Não aceita --duplo nem -hifens-nas-bordas-.

Uso típico: validar slugs de posts de blog, IDs de URL, chaves de produto antes de persistir.

Telefone brasileiro

^(?:\+55\s?)?(?:\(?\d{2}\)?\s?)?(?:9\s?\d{4}|\d{4})-?\d{4}$

Aceita celulares de 9 dígitos com ou sem o 9 inicial explícito, fixos de 8 dígitos, com ou sem DDD, com ou sem +55, com ou sem parênteses e hífens. Cobre os formatos que usuários brasileiros realmente digitam.

Teste antes de usar em produção com o Quick Tools Regex Tester — especialmente nos casos de borda com espaços e parênteses.

Cor hexadecimal

^#([0-9A-Fa-f]{3}|[0-9A-Fa-f]{6})$

Aceita #rgb e #rrggbb. Não aceita #rgba ou #rrggbbaa (8 chars) — se precisar de alpha, adicione |[0-9A-Fa-f]{8} ao padrão.

Simples, mas surpreende: a maioria das implementações esquece o # obrigatório ou não lida com letras maiúsculas.

Data no formato ISO 8601

^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$

Valida YYYY-MM-DD com mês e dia dentro dos intervalos válidos. Não valida dias impossíveis como 2026-02-30 — para isso, parse a string com new Date() e verifique se o resultado é Invalid Date.

Essa separação de responsabilidades é intencional: regex valida formato, código valida semântica.

Usando com confiança

Regex não substitui validação semântica nem verificação de existência. Use-as como primeira camada de filtragem — para falhar rápido antes de processar dados claramente inválidos. A validação real (e-mail existe? data faz sentido? CNPJ é válido?) sempre precisa de código além do padrão.

Para testar qualquer uma dessas expressões com seus dados reais, o Regex Tester mostra os matches em tempo real com highlight de grupo.

Como testar regex sem cair em falsos positivos

Uma regex parece correta quando passa no exemplo feliz. O problema aparece nos casos que deveriam falhar. Para cada padrão, mantenha duas listas: entradas válidas e entradas inválidas. Em e-mail, teste domínio sem TLD, espaços, acentos e dois pontos. Em slug, teste hífen duplo, hífen no início e uppercase. Em data, teste mês 13 e dia 00.

Também observe se a regex está ancorada com ^ e $. Sem âncoras, ela pode aceitar uma string inteira só porque encontrou um trecho válido dentro dela. Isso é uma das causas mais comuns de validação permissiva demais.

Checklist de produção

Antes de colocar uma regex em produção, defina o que ela não pretende validar. A regex de e-mail valida formato, não existência. A regex de data valida estrutura, não calendário completo. A regex de telefone aceita formatos comuns, mas não garante que o número existe.

Teste os padrões no Regex Tester, salve exemplos de entrada e transforme os casos principais em testes automatizados. Regex sem testes vira conhecimento tribal rapidamente.

Perguntas frequentes

Regex deve validar tudo?

Não. Use regex para rejeitar entradas obviamente inválidas e deixe validação semântica para código especializado.

Revisão antes do merge

Em revisão de código, peça exemplos reais junto com a regex. Um padrão sem amostras é difícil de avaliar. Bons exemplos mostram entradas válidas, inválidas e casos de borda. Isso reduz a chance de uma regex funcionar no teste feliz e falhar silenciosamente em produção.

Segurança e performance

Evite regex complexa demais em entradas grandes sem testar performance. Alguns padrões com grupos repetidos podem causar backtracking caro. Quando a entrada vem de usuário, prefira padrões simples, limites de tamanho e validação em etapas.