Padrões de Regex que Todo Desenvolvedor Deveria Salvar nos Favoritos

Navegar
Voltar ao blog
Publicado
April 15, 2026
Tempo de leitura
8 min de leitura
Escrito por
Sophie Parker
Referência de padrões regex comuns com sintaxe de correspondência destacada em fundo escuro de editor

Padrões regex são templates reutilizáveis que identificam sequências específicas de caracteres em um texto - pense neles como uma ferramenta de "busca" turbinada, que funciona em praticamente qualquer linguagem de programação. Seja para validar um endereço de e-mail, extrair um número de telefone de um formulário ou analisar um arquivo de log, um conjunto bem escolhido de expressões regulares resolve 90% do que você precisa. Este guia reúne os padrões mais úteis na prática, explica exatamente o que cada um faz e mostra como adaptá-los.

Índice

Revisão Rápida de Sintaxe Regex

Antes de mergulhar nos padrões, confira este resumo dos blocos de construção que você vai encontrar repetidamente. Mesmo que você já tenha usado regex antes, é útil ter tudo isso em um só lugar.

Token Significado Exemplo de correspondência
. Qualquer caractere, exceto nova linha a.c corresponde a abc , a1c
\d Qualquer dígito (0-9) \d\d corresponde a 42
\w Caractere de palavra (letras, dígitos, sublinhado) \w+ corresponde a hello_world
\s Espaço em branco (espaço, tabulação, nova linha) \s+ corresponde a múltiplos espaços
^ / $ Início / fim da string ^\d+$ corresponde apenas a 123
{n,m} Entre n e m repetições \d{2,4} corresponde de 12 a 1234
[abc] Classe de caracteres - qualquer um entre a, b, c [aeiou] corresponde a qualquer vogal
(?:...) Grupo sem captura Agrupa sem armazenar uma referência retroativa
(?=...) Lookahead positivo Verifica o que vem a seguir sem consumi-lo

O guia de expressões regulares do MDN Web Docs é a melhor referência única para sintaxe regex em JavaScript, e a maioria dos padrões abaixo se aplica diretamente ao Python, PHP, Java e Ruby, com pequenas diferenças de flags.

Validação de E-mail

E-mail é o caso de uso clássico de regex - e também aquele em que a maioria dos desenvolvedores erra ao tentar ser restrita demais. A especificação RFC 5322 tecnicamente permite endereços como "very unusual"@example.com , que quase nenhum regex consegue tratar. Para 99% da validação de entrada no mundo real, use um padrão pragmático: 

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

O que cada parte faz:

  • [a-zA-Z0-9._%+\-]+ - parte local (antes do @); permite pontos, sinais de mais, hifens e sublinhados
  • @ - o símbolo @ literal
  • [a-zA-Z0-9.\-]+ - nome de domínio, incluindo subdomínios
  • \.[a-zA-Z]{2,} - TLD com pelo menos 2 caracteres (.io, .com, .museum)
O regex por si só não confirma se um endereço de e-mail existe ou pode receber mensagens. Sempre envie um e-mail de confirmação para qualquer coisa que realmente importe.

URLs e Endereços Web

O pattern matching de URLs cobre desde a extração de links em texto simples até a validação de um campo de site informado pelo usuário. 

https?:\/\/(?:www\.)?[-a-zA-Z0-9@:%._+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b(?:[-a-zA-Z0-9()@:%_+.~#?&\/=]*)
  • https? - corresponde tanto a http quanto a https
  • (?:www\.)? - prefixo www opcional
  • [-a-zA-Z0-9@:%._+~#=]{1,256} - caracteres do hostname, até 256 caracteres
  • \.[a-zA-Z0-9()]{1,6} - TLD
  • \b(?:[-a-zA-Z0-9()@:%_+.~#?&\/=]*) - caminho, query string e fragmento opcionais

Se você só precisa validar (e não extrair), envolva o padrão com as âncoras ^ e $ .

Números de Telefone

Números de telefone são notoriamente complicados porque a formatação varia muito por país e pelo hábito de cada usuário. Dois padrões cobrem a maioria dos cenários:

Formato EUA/Canadá (NANP) 

^(\+1[-.\s]?)?(\(?\d{3}\)?[-.\s]?)?\d{3}[-.\s]?\d{4}$

Corresponde a: 555-867-5309 , (555) 867 5309 , +1.555.867.5309 , 5558675309

Internacional (formato E.164) 

^\+[1-9]\d{6,14}$

E.164 é o formato usado pela maioria das APIs de telefonia (Twilio, AWS SNS). Começa com + e um código de país, sem espaços ou pontuação.

Para qualquer coisa além de uma verificação básica de formato - como confirmar se um número é realmente uma linha móvel válida em um país específico - use uma biblioteca dedicada como a libphonenumber (biblioteca open-source do Google para números de telefone, disponível em Java, JavaScript, Python e mais).

Datas e Horários

O pattern matching de datas é comum em parsers de log, validadores de formulários e pipelines de dados. O formato que você precisa depende da sua fonte de entrada.

ISO 8601 (YYYY-MM-DD) 

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

Formato norte-americano (MM/DD/YYYY) 

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

Horário no formato 24 horas (HH:MM ou HH:MM:SS) 

^([01]\d|2[0-3]):([0-5]\d)(?::([0-5]\d))?$

Observe que esses padrões validam o formato, não a lógica do calendário. Eles aceitarão 2024-02-31 (31 de fevereiro não existe). Para uma validação de data rigorosa, faça o parse com a biblioteca de datas da sua linguagem após a verificação com regex.

Validação de Força de Senha

As regras de senha geralmente exigem uma combinação de tipos de caracteres e um comprimento mínimo. Lookaheads tornam isso mais limpo sem precisar de múltiplas verificações separadas.

Mínimo de 8 caracteres, pelo menos uma letra maiúscula, uma minúscula e um dígito 

^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,}$

Senha forte: 8+ caracteres, maiúscula, minúscula, dígito e caractere especial 

^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[!@#$%^&*()_+\-=\[\]{};':"\\|,.<>\/?]).{8,}$

Cada (?=.*[...]) é um lookahead que percorre toda a string em busca de pelo menos um caractere correspondente. O .{8,} final impõe o comprimento mínimo. Você pode substituir {8,} por {12,} para exigir no mínimo 12 caracteres, o que está alinhado com as diretrizes NIST SP 800-63B .

Endereços IP

IPv4 

^(?:(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(?:25[0-5]|2[0-4]\d|[01]?\d\d?)$

Este padrão rejeita corretamente valores como 999.0.0.1 ao verificar cada octeto explicitamente no intervalo de 0 a 255.

IPv6 (simplificado) 

^([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}$

Este padrão cobre o formato completo de 8 grupos. Para a notação comprimida (por exemplo, ::1 para loopback), o padrão se torna significativamente mais complexo - nesse ponto, usar uma biblioteca de rede é mais confiável do que regex.

HTML e Markup

Alguns padrões específicos são genuinamente úteis aqui. O conselho geral de "não faça parse de HTML com regex" ainda vale para documentos completos - use um parser de DOM adequado como BeautifulSoup ou DOMParser para isso. Mas para tarefas específicas e bem delimitadas, regex funciona perfeitamente.

Remover todas as tags HTML 

<[^>]*>

Extrair conteúdo de uma tag específica (por exemplo, <title>) 

([^<]*)<\/title>

O grupo de captura 1 contém o texto do título.

Corresponder a códigos de cor hexadecimais HTML 

#([a-fA-F0-9]{6}|[a-fA-F0-9]{3})\b

Corresponde tanto à forma abreviada de 3 dígitos ( #fff ) quanto à forma completa de 6 dígitos ( #ffffff ).

Padrões Utilitários do Dia a Dia

Estes aparecem com frequência em diferentes tipos de projetos.

Slug (string amigável para URL) 

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

Corresponde a strings como my-blog-post-2024 . Sem letras maiúsculas, sem hifens no início ou no fim, sem hifens duplos.

Número de cartão de crédito (formato básico, sem espaços) 

^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|3[47][0-9]{13}|6(?:011|5[0-9]{2})[0-9]{12})$
  • Começa com 4 - Visa (13 ou 16 dígitos)
  • Começa com 51-55 - Mastercard (16 dígitos)
  • Começa com 34 ou 37 - Amex (15 dígitos)
  • Começa com 6011 ou 65 - Discover (16 dígitos)
Nunca armazene números de cartão brutos. Este padrão serve apenas para feedback de formato no lado do cliente. A validação real do cartão deve passar por um processador compatível com PCI, como Stripe ou Braintree.

Normalização de espaços em branco (colapsar múltiplos espaços) 

\s{2,}

Substitua as correspondências por um único espaço para limpar entradas de usuário bagunçadas ou texto extraído por scraping.

Somente dígitos 

^\d+$

Somente alfanuméricos 

^[a-zA-Z0-9]+$

Corresponder a uma linha que contém uma palavra (sem distinção de maiúsculas/minúsculas com flag) 

^.*\bword\b.*$

O limite de palavra \b evita que word seja encontrado dentro de password .

Extrair números de versão (semver) 

\bv?(\d+)\.(\d+)\.(\d+)(?:-([a-zA-Z0-9.]+))?(?:\+([a-zA-Z0-9.]+))?\b

Captura major, minor, patch, rótulo de pré-lançamento e metadados de build a partir de strings como v2.14.0-beta.1+build.42 .

Flags e Dicas Práticas

Os padrões regex se comportam de forma diferente dependendo das flags aplicadas. As mais comumente necessárias:

Flag JS Python Efeito
Sem distinção de maiúsculas/minúsculas i re.IGNORECASE Trata maiúsculas e minúsculas como iguais
Global (encontrar todas) g re.findall() Retorna todas as correspondências, não apenas a primeira
Multilinha m re.MULTILINE ^ e $ correspondem aos limites de cada linha, não da string inteira
Dotall s re.DOTALL . também corresponde a caracteres de nova linha

Alguns hábitos que vão te poupar tempo de depuração:

  • Sempre teste com casos extremos - string vazia, comprimento máximo, caracteres Unicode e strings que são quase, mas não completamente, válidas.
  • Use grupos sem captura (?:...) quando você não precisa do conteúdo correspondido - é mais rápido e mais limpo do que grupos de captura.
  • Ancore seus padrões de validação com ^ e $ para que uma substring aparentemente válida dentro de uma string inválida não passe despercebida.
  • Cuidado com o backtracking catastrófico - quantificadores aninhados como (a+)+ podem fazer o motor de regex travar com entradas manipuladas. Mantenha os quantificadores simples e específicos.
  • Use um testador de regex enquanto constrói seus padrões. regex101.com exibe uma análise ao vivo das correspondências, explica cada token e permite alternar entre os modos PCRE, JavaScript, Python e outros.
Ferramentas de pattern matching com regex e validação de entrada

Teste e valide padrões regex sem achismos

Criar padrões regex confiáveis para validação de entrada é muito mais rápido quando você tem as ferramentas certas à mão. Explore nossos utilitários gratuitos para desenvolvedores e limpe, verifique e transforme texto usando regex e muito mais.

Experimente Nossas Ferramentas Gratuitas →

Quantificadores gulosos (como .* ) correspondem ao máximo possível e depois fazem backtracking. Quantificadores preguiçosos (como .*? ) correspondem ao mínimo possível. Por exemplo, na string bold , o padrão <.*> corresponde à string inteira, enquanto <.*?> corresponde apenas a . Use quantificadores preguiçosos ao extrair conteúdo entre delimitadores.

Na maioria das vezes sim, mas há diferenças. O módulo re do Python usa sintaxe no estilo PCRE e suporta grupos nomeados com (?P...) . O JavaScript usa uma sintaxe de flags ligeiramente diferente e não suporta lookbehinds em motores mais antigos (anteriores ao ES2018). Para código que funcione em múltiplas linguagens, fique com o subconjunto comum: classes de caracteres, quantificadores, âncoras e grupos básicos.

Regex é perfeitamente adequado para validação de formato em produção - é usado em praticamente todos os frameworks web. Os riscos estão em padrões mal escritos que permitem ataques ReDoS (negação de serviço via regex) por backtracking catastrófico. Evite quantificadores aninhados, mantenha os padrões específicos e sempre defina um limite razoável de comprimento de entrada antes de o regex sequer ser executado.

Na maioria dos motores comuns, eles são equivalentes para entrada ASCII. A diferença aparece com Unicode: \d em alguns motores (como Python 3 com modo Unicode) pode corresponder a dígitos de outros sistemas de escrita, como os numerais indo-arábicos. Se você quer estritamente os dígitos ASCII de 0 a 9, use [0-9] para ser explícito. Para a maioria da validação de formulários web, essa distinção não faz diferença.

Você precisa de duas coisas: a flag dotall (para que . corresponda a novas linhas) e possivelmente a flag multilinha (para que ^ e $ ancorem em cada linha em vez de na string inteira). Em JavaScript, use /pattern/ms . Em Python, combine re.DOTALL | re.MULTILINE . Sem o dotall, . para nas quebras de linha e seu padrão não abrangerá múltiplas linhas.