Buscar y Reemplazar Texto Online — Regex y Sustitución Masiva
Pega cualquier trozo de texto — fichero de config, volcado de log, código fuente, borrador de prosa — escribe lo que quieres buscar, escribe el reemplazo y el resultado se actualiza en vivo con un contador de cuántas sustituciones se hicieron. Activa case-insensitive para lo obvio ("TODO" coincide con "todo") y activa modo regex para lo expresivo (grupos de captura, alternancia, anclas, clases de caracteres). Las cadenas de reemplazo soportan `$1`, `$2` etc. como backreferences en modo regex, así que "`(\w+) (\w+)`" con reemplazo "`$2 $1`" intercambia cada par de palabras. Útil para limpiar datos exportados, corregir una errata en un documento largo, refactorizar patrones en código sin abrir un editor, normalizar espacios o renombrar masivamente entradas de una lista.
Sobre esta herramienta
Todo el reemplazo corre dentro de un Web Worker para que un regex de backtracking catastrófico (el clásico `(a+)+$` contra una cadena larga) no pueda congelar la página — si el worker no responde a tiempo se termina y ves un error amigable en vez de una pestaña colgada. En modo literal la cadena de búsqueda se escapa frente a los caracteres especiales del regex antes de pasarse a un RegExp global, así que `.`, `*`, `(`, `)` etc. se buscan a sí mismos en vez de actuar como metacaracteres. En modo regex tu patrón se usa tal cual con el flag `g` (siempre reemplaza todas las apariciones) más `i` cuando está activo case-insensitive, y el reemplazo usa la semántica estándar de `String.prototype.replace` de JavaScript — `$&` para el match completo, `$1`-`$9` para grupos de captura, `$$` para un dólar literal. Los errores (paréntesis desbalanceados, clase de caracteres inválida, lookbehind no soportado en el runtime) se muestran inline en vez de producir silenciosamente la salida equivocada. Casos de uso: redactar una lista de emails con un solo regex, intercambiar `apellido, nombre` por `nombre apellido` con backreferences, normalizar finales de línea, quitar códigos de color ANSI de un log copiado del terminal o reformatear teléfonos de `(123) 456-7890` a `+34-123-456-7890`.
- Modo literal — cadena de búsqueda escapada, sin sorpresas de sintaxis regex
- Modo regex — regex JavaScript completo con grupos de captura + backreferences
- Toggle case-insensitive (añade flag `i` en modo regex)
- El reemplazo soporta $1-$9 backreferences y $& para el match completo
- Aislamiento Web Worker — el backtracking catastrófico no congela la página
- Timeout del worker dispara un error amigable en vez de colgar la pestaña
- Contador en vivo de cuántas sustituciones ocurrieron
- Mensajes de error regex inline (paréntesis desbalanceados, clase inválida, etc.)
- Reactivo — corre mientras editas cualquiera de los tres campos
- Útil para redacción, refactor, normalización de datos, errata repetida
Gratis. Sin registro. Tus datos permanecen en tu navegador. Anuncios mediante Google AdSense (con consentimiento).
Preguntas frecuentes
¿Qué es el backtracking catastrófico y cómo ayuda el Web Worker?
El backtracking catastrófico ocurre cuando una regex con cuantificadores anidados (el clásico benchmark `(a?){29}a^29` que usa Cox, o `(a+)+$` contra una cadena larga de 'a's seguida de 'b') prueba todas las divisiones posibles entre los grupos interno y externo antes de fallar. A medida que la entrada crece, el número de combinaciones de división crece exponencialmente. El artículo de 2007 de Russ Cox 'Regular Expression Matching Can Be Simple And Fast' (swtch.com) demostró que los motores con backtracking (Perl, Python, JavaScript) pueden tardar más de 60 segundos en una entrada patológica de 29 caracteres que los motores Thompson-NFA (la construcción que Thompson describió en CACM 1968) emparejan en 20 microsegundos. La regex de JavaScript usa backtracking, así que un patrón malicioso o accidental con cuantificadores anidados sobre una cadena larga congelaría la página. Ejecutar la regex dentro de un Web Worker (definido en el WHATWG HTML Living Standard) hace que corra en un hilo separado; si el worker no responde antes de un timeout configurado, el hilo principal lo termina vía el algoritmo terminate-a-worker de WHATWG y muestra un error.
¿Por qué el modo literal escapa los caracteres especiales de regex?
ECMA-262 especifica que una cadena del constructor RegExp interpreta `.`, `*`, `+`, `(`, `)`, `[`, `]`, `?`, `\\`, `^`, `$`, `|`, `{`, `}` como metacaracteres con sus respectivos significados regex. Las cadenas de búsqueda en modo literal necesitan que estos caracteres se emparejen consigo mismos: `.` debe emparejar un punto, no cualquier carácter; `*` debe emparejar un asterisco, no actuar como cuantificador. La pasada de escape envuelve cada metacarácter con una contrabarra antes de pasar la cadena al constructor RegExp, así que `(nombre)` se convierte en `\\(nombre\\)` y empareja el texto literal '(nombre)'. Sin escape, una búsqueda en modo literal de `.com` emparejaría toda secuencia de tres caracteres que termine en 'com', que rara vez es lo que el usuario quiere.
¿Cómo funcionan $1, $& y otras referencias de reemplazo?
El String.prototype.replace de ECMA-262 define la sintaxis de cadena de reemplazo: `$&` es el match completo, `$\`` (acento grave) es la porción de entrada antes del match, `$'` (apóstrofe) es la porción posterior, y `$1`–`$9` referencian grupos de captura numerados en el patrón regex. En modo regex, un patrón como `(\\w+) (\\w+)` con reemplazo `$2 $1` intercambia cada par adyacente de tokens de palabra. ES2018 añadió grupos nombrados: `(?<primero>\\w+) (?<segundo>\\w+)` con reemplazo `$<segundo> $<primero>` hace lo mismo con nombres. Un `$` literal en el reemplazo se escribe `$$`. El replace de JavaScript NO reconoce los escapes con contrabarra (`\\1`, `\\n`) de POSIX/Perl regex — solo las formas con signo de dólar.
¿Esta herramienta admite características modernas de regex — lookbehind, grupos nombrados, Unicode property escapes?
Sí. La herramienta usa la RegExp del runtime de JavaScript directamente, así que cualquier característica que el motor del navegador admita está disponible — lookbehind `(?<=...)` y `(?<!...)` desde ES2018, grupos de captura nombrados `(?<nombre>...)` y referencias `\\k<nombre>` desde ES2018, Unicode property escapes `\\p{Letter}` y `\\P{Number}` desde ES2018 (con la bandera `u`), y la bandera `s` (dotAll) desde ES2018. Los navegadores más antiguos sin estas características (notablemente Safari 16.3 y anteriores para lookbehind) muestran un SyntaxError claro inline en lugar de producir silenciosamente una salida incorrecta. ECMA-262 NO admite grupos atómicos `(?>...)` ni cuantificadores posesivos (`*+`, `++`) que sí existen en PCRE/Perl/Java; para patrones donde los grupos atómicos serían la defensa natural contra backtracking, el enfoque más seguro es reescribir el patrón para evitar cuantificadores anidados por completo.
¿Cómo maneja esta herramienta la accesibilidad para lectores de pantalla?
El recuento de sustituciones y la región de resultado están dentro de una región aria-live="polite", el patrón del Criterio de Éxito 4.1.3 de WCAG (Mensajes de Estado, introducido en WCAG 2.1, recomendación del W3C del 5 de junio de 2018; trasladado sin cambios a WCAG 2.2, recomendación del 5 de octubre de 2023). Las regiones live polite encolan anuncios tras cualquier habla en progreso, así que editar los campos de búsqueda o reemplazo anuncia el nuevo recuento de sustituciones sin interrumpir al usuario a mitad de frase. Los lectores de pantalla (NVDA, JAWS, VoiceOver) consumen la región live automáticamente; el usuario no necesita hacer nada más.
Fuentes (5)
- ECMA International (2025). ECMAScript 2025 Language Specification — RegExp, String.prototype.replace, replacement patterns ($&, $1–$9, $<name>). ECMA-262, 16th edition, June 2025.
- Cox, R. (2007). Regular Expression Matching Can Be Simple And Fast (but is slow in Java, Perl, PHP, Python, Ruby, ...). swtch.com/~rsc/regexp/regexp1.html (canonical reference for catastrophic backtracking).
- Thompson, K. (1968). Programming Techniques: Regular expression search algorithm. Communications of the ACM, 11(6), 419–422 (Thompson NFA construction).
- WHATWG (2025). HTML Living Standard — Web Workers (DedicatedWorkerGlobalScope, terminate-a-worker algorithm). html.spec.whatwg.org/multipage/workers.html.
- World Wide Web Consortium (W3C) (2018). Web Content Accessibility Guidelines (WCAG) 2.1 — Success Criterion 4.1.3 Status Messages. W3C Recommendation 5 June 2018; carried unchanged into WCAG 2.2 (Recommendation 5 October 2023).
Son las publicaciones originales en las que se basan las fórmulas de esta herramienta. Localízalas con el nombre de la revista y el año en Google Scholar o PubMed.
Por Marco B. ·