Testador de Regex

Escopo: motor de regex do JavaScript

O teste roda com o RegExp nativo do navegador, sempre com a flag gaplicada internamente (exigida por matchAll). Lookahead e lookbehind são suportados ((?=...), (?!...), (?<=...),(?<!...)), exceto em versões de Safari anteriores à 16.4.

Referência rápida de sintaxe

• \d / \D — dígito / não-dígito
• \w / \W — caractere de palavra / não-palavra
• \s / \S — espaço em branco / não-espaço
• ^ / $ — início / fim (da string inteira, ou de cada linha com a flag m)
• \b — fronteira de palavra
• (?:...) — grupo não capturante
• (?<nome>...) — grupo de captura nomeado
• {n,m} — quantificador com limites (ex.: \d{2,4})
• *? / +? — quantificadores preguiçosos (menor match possível)

Casos de uso comuns

Validação de formato (e-mail, CPF, telefone com DDD) e extração via grupos de captura em logs, planilhas coladas ou respostas de API — a lista de grupos capturados aparece ao lado de cada ocorrência.

As flags e o que elas mudam

• g — percorre todas as ocorrências em vez de parar na primeira. Aplicada internamente aqui, já que matchAll a exige.
• i — ignora maiúsculas e minúsculas.
• m — faz ^ e $ casarem no início e no fim de cada linha, e não só da string inteira. É a flag que falta na maioria dos padrões que "não funcionam" em texto multilinha.
• s — faz o ponto casar também com quebra de linha, útil para capturar blocos que atravessam linhas.
• u — habilita o tratamento correto de caracteres Unicode fora do plano básico.

Guloso e preguiçoso, na prática

Quantificadores como * e + são gulosos por padrão: consomem o máximo possível e depois recuam até o padrão fechar. Isso produz o erro clássico de extração em HTML ou tags.

Sobre o texto <b>um</b> e <b>dois</b>, o padrão <b>.*</b> captura tudo de uma vez, do primeiro <b> até o último </b>. Já <b>.*?</b>, com o quantificador preguiçoso, devolve as duas ocorrências separadas — quase sempre o que se queria.

Backtracking catastrófico

Alguns padrões aparentemente inofensivos levam o motor a um número exponencial de tentativas. O caso típico é um quantificador dentro de outro, como (a+)+$ ou (\s*\w+)*$, aplicado a uma string que quase casa mas falha no fim.

Com dezenas de caracteres, o navegador pode travar por segundos ou minutos. Quando isso acontece em um servidor, com o padrão aplicado a entrada vinda do usuário, o resultado é uma vulnerabilidade de negação de serviço conhecida como ReDoS.

Se o teste aqui demorar de forma anormal com um texto pequeno, é sinal para revisar o padrão — provavelmente há aninhamento de quantificadores que pode ser reescrito de forma mais específica.

Padrões brasileiros úteis

• CEP — \d{5}-?\d{3}
• CPF formatado — \d{3}\.\d{3}\.\d{3}-\d{2}
• Telefone com DDD — \(?\d{2}\)?\s?9?\d{4}-?\d{4}
• Data no formato brasileiro — \d{2}/\d{2}/\d{4}

Uma ressalva importante: regex confere formato, não validade. Um padrão de CPF aceita111.111.111-11, que é sintaticamente perfeito e inválido na prática. A validação de verdade exige o cálculo do dígito verificador — para isso, use o validador de CPF ou o validador de CNPJ. E note que o CNPJ alfanumérico quebra qualquer padrão baseado apenas em \d.

O mesmo vale para e-mail: a especificação é complexa o bastante para que nenhuma regex razoável a cubra por completo. O caminho prático é verificar apenas a estrutura básica e confirmar a existência do endereço enviando uma mensagem — abordagem detalhada no validador de e-mail.

Processamento 100% local

Padrão, flags e texto de teste são processados inteiramente no navegador. Nada é enviado a servidor, então dá para testar contra dados sensíveis (e-mails de clientes, documentos, trechos de log) sem risco.