¿Qué es Probador de Regex?
El Regex Tester ejecuta tu expresion regular contra texto de ejemplo. Marca cada coincidencia en tiempo real mientras escribes. Activa o desactiva flags global, case, multiline, dotall, sticky y unicode con un clic. El tester se re-ejecuta con cada tecla. Muestra los grupos, las posiciones de inicio y fin de cada coincidencia, y el conteo total. El motor es el RegExp nativo del navegador. Las coincidencias aqui son las mismas que encontrara tu codigo JS real. Los devs lo usan para validaciones de formularios, parsers de logs y constructores de slugs. Cualquiera que aprenda regex recibe retroalimentacion visual al instante. Los grupos se muestran por numero o nombre. Las tareas comunes incluyen limpiar logs en busca de emails y numeros de tarjeta. Tambien ayuda a verificar formatos de entrada antes del envio de formularios.
¿Cuándo debo usar esta herramienta?
- Prueba un patrón de validación de email antes de lanzar un formulario de registro
- Verifica que un regex de slug de URL coincida con cada ruta de blog esperada
- Depura un grupo de captura mientras haces scraping de mensajes de error en logs
- Prototipa un patrón de buscar y reemplazar antes de ejecutarlo en producción
¿Cómo probar una expresión regular?
- 1Escribe o pega tu patrón regex en el campo de expresión.
- 2Activa banderas como global, sin distinción de mayúsculas o multilínea.
- 3Pega el texto de muestra que quieres comparar en el área de contenido.
- 4Observa las coincidencias resaltadas en vivo e inspecciona cada grupo de captura.
- 5Copia el patrón terminado en tu código o pipeline CI.
Preguntas frecuentes
¿Qué dialecto de regex usa este tester?
The tester runs the same ECMAScript regular expression engine that ships in your web browser — the same engine used by Node.js, Deno, and every Chromium-based or Firefox-based runtime. This matters because regex dialects differ in meaningful ways across languages, and testing in the wrong engine gives false confidence. The JavaScript engine supports the full ES2024 feature set, including named capture groups with the (?<name>...) syntax, Unicode mode activated by the /u flag, Unicode set notation activated by /v, lookbehind assertions of both positive (?<=...) and negative (?<!...) forms, the dotAll flag /s that makes . match newline characters, and the sticky flag /y that anchors the match to lastIndex rather than scanning. Features exclusive to other dialects are not available here. These include atomic groups (?>...) from PCRE and .NET, possessive quantifiers like a++ from Java, and variable-length lookbehind of the kind Python 3.x permits. If your production code is JavaScript or TypeScript running in a browser or Node.js, what passes here is guaranteed to behave identically in production. If you are porting a pattern to Python's re module, PHP's PCRE extension, or Go's RE2 engine, treat the result here as a starting reference and verify edge cases in the target engine. The tool exposes all six standard JS flags — g, i, m, s, u, y — as individual toggles so you can test the exact flag combination your code will use.
¿Cómo se actualizan los resaltados mientras escribo?
Every keystroke in either the pattern input or the test-string area triggers a synchronous re-evaluation cycle. The tester first attempts to compile the current pattern string into a RegExp object using the active flag set. If compilation throws a SyntaxError — for example, due to an unmatched parenthesis or an invalid flag — the pattern input border turns red and an error message shows the exact parse failure. No match attempt is made. If compilation succeeds, the engine runs the pattern against the full test string. In global mode the engine iterates through all non-overlapping matches and records the start index, end index, and all capture-group values for each. In non-global mode only the first match is collected. The DOM then receives updated highlight spans injected around each matched character range, color-coded by group number so nested captures are visually distinct. The entire cycle runs on the browser's main thread. Patterns that trigger catastrophic backtracking — the classic example is /(a+)+b/ tested against a long sequence of the letter a — can stall the thread for several seconds. To protect the tab, a 1 000-millisecond timeout aborts any match attempt that runs too long. When the timeout fires, a red warning banner identifies the pattern as potentially unsafe and recommends adding a possessive quantifier or atomic group equivalent. This prevents the tab from becoming unresponsive during exploration of untested patterns against large inputs.
¿Puedo guardar mis patrones o todo desaparece al recargar?
The tester automatically persists the current pattern, the selected flags, and the test-string content to the browser's localStorage under a key scoped to the WikiPlus origin. This save happens on every change with a short debounce, so you never need to click a save button. When you reopen the page — even after closing the tab or rebooting — the previous session is restored in full, including the capture-group summary panel. The saved state exists only in the browser profile on the device where it was entered. It is never synced to WikiPlus servers. Opening the same URL in an incognito or private window, or on a different device, starts with a blank tester. Clearing site data via browser settings also wipes the saved state. For sharing patterns with a colleague, the tester provides a share button that URL-encodes the pattern, flags, and a sample test string into the hash fragment — the portion of the URL after the # character. The hash is never sent to the server, so the shared URL does not expose the pattern to WikiPlus infrastructure. The recipient opens the link and sees the exact tester state you configured. For long-term storage of important patterns, copy them into a code comment, a README, or a team knowledge base. localStorage is persistent but not a reliable archive — users routinely clear browser data. The share URL approach is the safest way to hand off a finished pattern.
¿Por qué mi patrón se comporta diferente en Python o PHP?
Every programming language ships its own regex engine, and the engines differ in feature set, default behavior, and edge-case handling in ways that look minor but produce subtly wrong results in production. Python's re module uses its own flavor. It supports variable-length lookbehind that JavaScript rejects. It also treats \w as ASCII-only by default unless you pass re.UNICODE. PHP uses the PCRE2 library, which adds atomic groups, possessive quantifiers, recursive patterns, and callout functions — none of which exist in JavaScript. Java's java.util.regex implements yet another dialect with possessive quantifiers and different Unicode category handling. Go's RE2 engine deliberately omits all backtracking features, including lookahead and lookbehind, to guarantee linear-time matching. The meaning of \b word boundaries around Unicode letters also varies: JavaScript in /u mode treats Unicode letters as word characters, but many older engines treat only ASCII letters as word characters, making \b match at unexpected positions inside words that contain accented characters. Even the handling of \d differs — in some engines it matches only 0–9, in others it matches all Unicode decimal digit categories. When you test a pattern here for use in Python, PHP, or Go, treat the result as a functional draft and run a language-specific test suite before shipping. The most reliable approach is always to test the pattern inside the exact runtime your code will use.
El contenido de esta pagina esta disponible bajo CC BY 4.0.