Cómo Probar una Expresión Regular Online (Con Ejemplos Reales)
Para probar una expresión regular se escribe el patrón, se eligen los flags que necesita (g, i, m, s) y se ejecuta contra una cadena de prueba real, no contra el primer caso que se te ocurra. Después se revisan dos cosas antes de llevarla al código: qué partes del texto quedan resaltadas como coincidencia y qué captura cada grupo entre paréntesis, porque un patrón que “parece” correcto puede fallar en el caso límite que todavía no probaste.
Qué son el patrón y los flags
Un regex se escribe entre delimitadores / /, por ejemplo /\d{3}-\d{4}/. Todo lo que va dentro de esas barras es el patrón: la secuencia de caracteres literales, clases de caracteres y cuantificadores que describen qué texto buscar. Fuera de las barras van los flags, que cambian cómo se ejecuta ese patrón sin tocar su sintaxis. Hay exactamente cuatro:
- g (global): encuentra todas las coincidencias en el texto, no solo la primera. Sin este flag, el motor se detiene apenas encuentra un resultado.
- i (case-insensitive): ignora mayúsculas y minúsculas, así que
/hola/icoincide tanto conHolacomo conHOLA. - m (multiline): hace que
^y$coincidan con el inicio y el final de cada línea del texto, en vez de solo el inicio y el final de la cadena completa. - s (dotAll): hace que el punto
.también coincida con saltos de línea, algo que por defecto no hace.
Además del patrón y los flags está la captura. Cualquier parte del regex entre paréntesis () se convierte en un grupo capturado, un fragmento del texto que coincidió que puedes extraer por separado del resto. Y esos grupos pueden tener nombre: (?<year>\d{4}) captura cuatro dígitos bajo la etiqueta year, lo que hace mucho más legible el resultado cuando el patrón tiene varios grupos y no quieres depender del orden en que aparecen.
Ejemplos trabajados
Estos cuatro patrones cubren los casos que más se repiten en el día a día: validar un correo, extraer colores hexadecimales, parsear una ruta tipo API REST y validar una fecha con formato fijo.
| Patrón | Flags | Coincide | No coincide | Captura |
|---|---|---|---|---|
^[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}$ | ninguno | jane.doe@example.com | jane@example (sin dominio de nivel superior) | ninguna |
#([0-9a-fA-F]{6}|[0-9a-fA-F]{3}) | g | #2F7BFF, #fff | #12G456 (G no es hexadecimal) | Grupo 1: 2F7BFF |
\/(\w+)\/(\w[\w-]*) | g | /users/123, /products/abc-456 | /users (sin segundo segmento) | Grupo 1: tipo de recurso, Grupo 2: id |
^\d{4}-\d{2}-\d{2}$ | ninguno | 2026-07-11 | 07/11/2026 (formato incorrecto) | ninguna |
El patrón de rutas: \/(\w+)\/(\w[\w-]*)
Este es el patrón que usarías para validar o parsear una URL con forma /recurso/id, como las que expone cualquier API REST. Léelo de izquierda a derecha: \/ busca la barra literal (escapada porque en algunos contextos la barra es un delimitador), (\w+) captura uno o más caracteres alfanuméricos como primer grupo, luego otra \/ literal, y (\w[\w-]*) captura un segundo grupo que empieza con un carácter alfanumérico y puede seguir con letras, números o guiones. Con el flag g, /users/123/products/abc-456 no da una sola coincidencia sino dos: users/123 y products/abc-456, cada una con sus propios grupos. El grupo 1 te da el tipo de recurso (users, products), el grupo 2 te da el identificador (123, abc-456). Es exactamente la información que necesitas para armar un router simple: recorres las coincidencias, lees el grupo 1 para decidir a qué controlador despachar la petición, y el grupo 2 queda listo como el id que ese controlador va a buscar en la base de datos. Sin el guion dentro de la clase de caracteres del segundo grupo, abc-456 se cortaría en abc, así que ese detalle no es cosmético.
El patrón de color hexadecimal: #([0-9a-fA-F]{6}|[0-9a-fA-F]{3})
Aquí el # es literal, y el grupo ([0-9a-fA-F]{6}|[0-9a-fA-F]{3}) usa una alternancia: prueba primero seis caracteres hexadecimales (2F7BFF) y, si eso no encaja, prueba con tres (fff), que es la notación corta de CSS donde cada dígito se duplica. El flag g es lo que separa este caso de una simple validación: si estás escaneando una hoja de estilos completa para listar todos los colores de marca que aparecen, sin g el motor te devolvería solo el primer #2F7BFF que encuentre y se detendría ahí, aunque el archivo tenga quince colores distintos. Con g, cada coincidencia adicional se recorre y el grupo 1 de cada una te da el valor limpio sin el #, listo para meterlo en una lista, deduplicarlo o compararlo contra una paleta de referencia. Es la diferencia entre “encontré un color” y “extraje todos los colores del archivo”.
Pruébalo tú mismo
Escribe tu propio patrón, elige los flags y pégalo contra un texto real para ver de inmediato qué coincide y qué captura cada grupo.
Errores comunes y casos límite
Olvidar el modificador g. Sin él, el regex se detiene tras la primera coincidencia, rompiendo en silencio cualquier cosa que espere todas las ocurrencias, por ejemplo un “reemplazar todo” que solo termina reemplazando el primer resultado y deja el resto del texto intacto.
El punto sin escapar. Un . sin escapar coincide con cualquier carácter, no con un punto literal. Un patrón como 192.168.1.1 también coincide con 192X168X1X1, porque cada punto en la posición del patrón se interpreta como “cualquier carácter aquí”. Para exigir un punto real hay que escaparlo como \..
Cuantificadores codiciosos versus perezosos. .* toma todo lo posible, lo que se conoce como codicioso, y puede extenderse mucho más allá de lo esperado: en un bloque entero de HTML, un patrón con .* entre < y > puede coincidir desde el primer < hasta el último > del bloque, tragándose varias etiquetas de golpe en vez de una sola. .*?, la versión perezosa, se detiene en el primer punto posible donde el resto del patrón ya puede completarse.
Anclas ausentes. Sin ^ y $, un patrón puede coincidir como subcadena en cualquier parte del texto, así que un patrón pensado como “validación” puede aprobar una cadena que solo contiene una parte válida en algún punto, dejando pasar entradas que en realidad son inválidas. ^ y $ obligan a que el patrón coincida con la cadena completa, de principio a fin.
Preguntas frecuentes
¿Cuál es la diferencia real entre usar el modificador g y no usarlo? Sin g, el motor de regex se detiene apenas encuentra la primera coincidencia y descarta el resto del texto, sin importar cuántas otras coincidencias existan. Con g, sigue buscando hasta el final de la cadena y devuelve todas las coincidencias encontradas. La diferencia importa sobre todo en operaciones de reemplazo o extracción masiva: sin g solo se toca o se extrae la primera ocurrencia, con g se procesan todas.
¿Cómo hago coincidir un carácter especial literal como un punto, un signo de dólar o un paréntesis?
Se escapa con una barra invertida delante: \. para un punto literal, \$ para un signo de dólar literal, \( y \) para paréntesis literales. Estos caracteres tienen un significado especial en regex (el punto es “cualquier carácter”, el dólar es “fin de línea”, los paréntesis abren un grupo), así que sin el escape el motor los interpreta como sintaxis en vez de como texto a buscar.
¿Qué es un grupo no capturante, (?:...), y cuándo lo necesito en lugar de un grupo (...) normal?
Un grupo no capturante agrupa parte del patrón, por ejemplo para aplicarle un cuantificador o una alternancia a varios caracteres juntos, pero no guarda ese fragmento como resultado capturado. Se usa cuando necesitas la agrupación por razones de sintaxis pero no te interesa extraer ese texto después: mantiene la lista de grupos capturados limpia y con solo los datos que realmente vas a usar, en vez de llenarla con fragmentos intermedios que solo servían para la estructura del patrón.
¿Esta herramienta envía mi patrón o texto de prueba a algún lugar? No. Todo se ejecuta en el navegador con el motor nativo RegExp de JavaScript, así que ni el patrón ni el texto de prueba se envían a ningún servidor. Puedes probar datos sensibles sin preocuparte de que salgan de tu propia máquina.