Testador de Expressões Regulares (Regex)

Uma expressão regular, ou regex, é um padrão de texto usado para encontrar, validar ou substituir sequências de caracteres. O padrão '\d{3}-\d{4}', por exemplo, encontra números no formato 000-0000, e '\d{5}-\d{3}' encontra um CEP escrito com hífen. Regex existe em quase toda linguagem de programação, em editores como o VS Code e em comandos como grep e sed. A sintaxe básica é parecida em todos eles, mas os recursos avançados mudam de uma implementação para outra.

Flags mudam o comportamento do padrão. A g encontra todas as ocorrências, e não só a primeira; a i ignora a diferença entre maiúscula e minúscula; a m faz ^ e $ valerem no começo e no fim de cada linha; a s faz o ponto casar também a quebra de linha; a u liga o modo Unicode, necessário para \p{L}; a y prende a busca à posição onde a anterior terminou. Nesta página a g fica sempre ligada. No texto de exemplo da tabela, ^\w+ acha 1 ocorrência sem a m e 3 com ela.

Grupos de captura são as partes do padrão entre parênteses. Eles guardam o trecho que casou para você usar depois, numa substituição ou no código. Em '(\d{4})-(\d{2})' aplicado a '2026-05', o grupo 1 captura '2026' e o grupo 2 captura '05'. Grupos nomeados usam a forma (?<nome>padrão) e aparecem pelo nome: na tabela desta página, (?<reais>\d+),(?<centavos>\d{2}) separa o valor do texto em reais = 189 e centavos = 90. Para agrupar sem capturar, use (?:padrão).

ReDoS acontece quando uma regex com backtracking catastrófico roda contra um texto que quase casa: o motor testa um número exponencial de caminhos, e o tempo explode a cada caractere a mais. Padrões como '(a+)+' ou '([a-z]+)+@' são o caso clássico, e algumas dezenas de caracteres bastam para travar uma aba. Esta página roda o teste num Web Worker separado, com limite de 2 segundos, e encerra o Worker quando o tempo estoura. Esse limite protege a página, não o seu sistema: um padrão que estoura aqui continua sendo uma porta de negação de serviço no seu servidor.

Porque uma expressão regular já em execução não pode ser interrompida de dentro da mesma thread. Nem try/catch nem temporizador funcionam: o try/catch só age quando algo lança exceção, e backtracking catastrófico não lança nada, apenas não termina. Enquanto isso, a thread está presa no regex e não processa cliques nem temporizadores. Rodando em um Web Worker, a página continua livre e consegue encerrar o Worker, que é a única forma real de cancelar a execução.

Não. O padrão e o texto de teste são processados no próprio navegador, pela engine de regex nativa do JavaScript, dentro de um Web Worker da mesma página. Nada é transmitido para servidor, nada fica gravado, e a lista de ocorrências some quando você fecha a aba. Por isso dá para testar padrões contra trechos de log ou de planilha interna sem expor o conteúdo. Com a página já carregada, a ferramenta continua funcionando mesmo sem conexão.

Não. O padrão é tratado como texto e compilado pela engine de regex do JavaScript com new RegExp(padrão, flags). A página não usa eval() nem nada parecido, e o resultado aparece como texto comum, sem ser interpretado como HTML. Um padrão malformado, como um parêntese sem fechar, só produz a mensagem Regex inválida, com a explicação da própria engine. O pior que um padrão consegue fazer é demorar demais, e para isso existe o limite de 2 segundos do Web Worker.

Porque no JavaScript o \w é só [A-Za-z0-9_]: letras sem acento, dígitos e sublinhado. O ç, o ã e o é ficam de fora, e uma palavra como João é cortada em dois pedaços. Para aceitar letra com acento, use \p{L}, que casa qualquer letra de qualquer alfabeto, e ligue a flag u, sem a qual o \p{L} não funciona. Na tabela desta página, 'de \w+' devolve 'de Jo', e 'de \p{L}+' com a flag u devolve 'de João'. Para incluir também dígitos e sublinhado, use [\p{L}\p{N}_].

Nem sempre. Esta página usa a engine do JavaScript, a mesma do Node e dos navegadores. O básico, como classes de caracteres, quantificadores e grupos, funciona igual no Python, no Java e no PHP. As diferenças aparecem nos recursos avançados: o PCRE, que o PHP usa, tem quantificador possessivo e recursão, que o JavaScript não tem; o RE2, usado no Go, não aceita lookahead, lookbehind nem retrovisor, em troca de tempo de execução linear. Teste na linguagem de destino antes de levar o padrão para produção.

Para o CEP com hífen, use \d{5}-\d{3}, ou \d{5}-?\d{3} para aceitar também sem hífen. Para o CPF formatado, \d{3}\.\d{3}\.\d{3}-\d{2}, com o ponto escapado, porque o ponto sozinho casa qualquer caractere. Para a data, \d{2}/\d{2}/\d{4}. A regex confere o formato, não a validade: 31/02/2026 passa no padrão de data, e um CPF com dígito verificador errado passa no de CPF. Conferir os dígitos exige uma conta, e regex não faz conta.

São os detalhes de cada item da lista. O índice é a posição do primeiro caractere da ocorrência, contada a partir de zero: índice 0 é o começo do texto. Grupos mostra, entre colchetes, o que cada grupo de captura guardou, na ordem em que os parênteses abrem no padrão; (?:...) e lookaround não entram. Um traço aparece quando o grupo existe mas não participou daquela ocorrência, como numa alternativa que não foi usada. A busca para em 200 ocorrências: com mais do que isso, a lista e o contador no alto mostram 200.

É a caixa amarela que aparece quando o padrão tem um quantificador dentro de outro, como (a+)+ ou (\d*)*. O teste roda normalmente, e o aviso só explica o risco: contra um texto que quase casa, esse formato faz o motor testar caminhos em número exponencial, que é a causa do ReDoS. Muitos padrões assim funcionam bem na prática, por isso a página avisa em vez de recusar. Para tirar o risco, reescreva o grupo interno sem o quantificador ou use um grupo atômico na linguagem de destino, quando ela tiver.