Regex-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.

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.

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.

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.