Lua Pattern Tester

No, and assuming they are is the most common source of bugs. Lua patterns are a small, deliberately simple matching language implemented in about 200 lines of C, not a regular expression engine. The differences bite immediately. There is no alternation: the pattern a|b matches the literal three-character string "a|b", not "a" or "b". There are no non-capturing groups, no lookahead or lookbehind, no named captures, no backreferences inside the pattern itself, no {n,m} repetition counts, and no case-insensitive flag. Escaping uses a percent sign rather than a backslash, so a literal dot is %. and a literal percent is %%. Character classes are single letters after a percent: %a for letters, %d for digits, %s for whitespace, %w for alphanumerics, and the uppercase form of each is its complement. In exchange for what it gives up, Lua adds two things regex does not have: %b for balanced delimiter matching and %f for frontier assertions. This tester runs your pattern through a real Lua 5.4 virtual machine, so what you see here is exactly what your Lua code will do.

These are the two features Lua patterns have that regular expressions lack, and both are genuinely hard to replicate elsewhere. %bxy matches a balanced run of text starting with character x and ending with the matching character y, counting nesting as it goes. So %b() applied to the string f(a(b)c)d matches (a(b)c) in full rather than stopping at the first closing parenthesis, which is what makes it the right tool for extracting nested brackets, braces, or parenthesised expressions — something a regular expression fundamentally cannot do without recursion extensions. %f[set] is a frontier pattern: it matches the empty string at any position where the previous character is not in the given set and the next character is. It behaves like a generalised word boundary, so %f[%a]%a+%f[%A] matches whole words without consuming the characters on either side. Because a frontier matches empty, it never advances the position by itself, which makes it safe to combine with other patterns.

Because it was still running after the time limit, and the tool killed it rather than let it freeze your browser tab. Lua patterns cannot suffer the exponential catastrophic backtracking that regular expressions can, since they have no alternation, but they can still be far worse than linear. The shape to watch for is several unbounded quantifiers in sequence: a pattern such as .-.-.-.-.-c makes each quantifier scan the entire remaining subject for every position the one before it tries, which multiplies out very quickly. On a few thousand characters that pattern runs for minutes. Even a single nested pair like (%a*)*c costs time proportional to the square of the subject length. The fix is almost always to bound the quantifiers instead of leaving them open: replace .- with a negated class that cannot cross the delimiter you care about, so <(.-)> becomes <([^>]*)>. That change alone usually turns a pathological pattern into a linear one. Shortening the subject also helps, since the cost scales with its length.

No. The Lua virtual machine is compiled to WebAssembly and runs inside a Web Worker in your own browser, so both the pattern and the subject text stay on your machine. There is no API call, no logging, and nothing to opt out of, which means the tool is safe to use on production log lines, configuration files, and other text you would not paste into a hosted service. The worker exists for a second reason beyond privacy: because Lua's matcher is C code inside the WebAssembly module, a long-running match cannot be interrupted from inside Lua at all — an instruction-count debug hook never fires, because no Lua instructions execute while the C matcher runs. Terminating the worker from the main thread is the only reliable way to stop it, and that is only possible because the virtual machine lives off the main thread. Your pattern and subject cross into Lua as argument values rather than being concatenated into Lua source, so a pattern cannot inject code.