Regular expression visual parsing/syntax illustration tool | ZeroTools

The notation breakdown feature uses a simple lexical analysis engine that sequentially scans the regex from the beginning and splits it into tokens.

It does not perform complex compilation like building an AST or converting to an NFA or DFA. Instead, it presents an intuitive notation list.

During parsing, the string index advances one character at a time. Specific symbols and escape sequences are extracted as semantic chunks, isolating anchors like caret (^) or dollar sign ($), character classes like \d (ASCII 0-9) or \w (alphanumeric and underscore) following a backslash, word boundaries like \b, or range specifications in brackets ([]).

Because it relies on a one-dimensional scan without deep states, it operates lightly for simple inputs, though processing time varies.

While this simplified approach does not directly reproduce the engine's internal behavior, it fulfills a visualization role for beginners understanding regex elements and experts checking long patterns.

It helps visually detect unintended escapes but does not guarantee the discovery of all syntax omissions.

Each token split by the lexical analysis engine is classified into types based on its syntactic role and visualized as a list on the screen with explanations.

Categories include anchors indicating the start or end of a line, character classes defining specific character sets, groups wrapping patterns, quantifiers specifying the number of repetitions, lookaheads handling positive lookahead assertions (which assert the position is immediately followed by the pattern) and negative lookahead assertions (which assert the position is not followed by the pattern), and literal characters with no special meaning.

On the screen, different background colors and badges are assigned to these classifications, designed so the overall structure can be grasped as color-coded blocks.

Consistent coloring is applied—orange for anchors, blue for character classes, purple for groups, and green for quantifiers. Regarding UI layout, the actual syntax string is highlighted in a monospace font on the left side, while specific English explanations are arranged on the right.

This employs a vertical list from left to right, eliminating graphical syntax or railroad diagram rendering, allowing smooth scrolling even for long patterns.

Independent of the notation breakdown display, the validation feature that determines how the pattern actually matches the test text is executed in a dedicated Web Worker with a 1,000 ms deadline, directly invoking the browser's JavaScript RegExp object.

As a result, the input regular expression is evaluated locally without being sent to a server. Internally, matching is managed such that modifying settings or leaving the page stops prior requests.

To maintain performance, the tool applies limits of 2,000 characters for the pattern, 100,000 UTF-16 code units for the test text, up to 5,000 matches, and an estimated result text cap of 8 MiB, notifying the user when limits are reached.

When zero-width matches occur with the Unicode u flag, the engine advances by 2 code units only for a surrogate pair, and by 1 code unit otherwise.

If Worker execution is unavailable, there is no fallback to the main thread. The tool supports pattern modification by catching syntax exceptions and feeding them back as warning messages, reflecting native engine behavior while protecting the UI.

In the practical application of regular expressions, the capture function, which extracts specific substrings from matched portions rather than just determining whether a string matches, is highly important.

Based on the test results from the RegExp engine, this tool features a mechanism that lists the extracted contents of capture groups defined by parentheses, along with their index numbers and the overall matched string.

During the evaluation process, the JavaScript exec method is used to enumerate all matching locations within the text. For instance, testing a postal code pattern with a multi-line string using ^...$ and only the g flag might yield 0 matches, whereas applying the gm flag can correctly yield 2 matches.

Without the global flag, only the first match is returned, and with only the y flag, it matches with lastIndex set to 0. When the global flag (g) is active, a while loop continues the search until there are no more matches, and control is implemented to appropriately increment the engine's lastIndex property.

However, for a zero-width match with the g flag, lastIndex is incremented by code unit. This means it may step inside a surrogate pair when the u flag is active, which could potentially cause the engine to halt, and it does not guarantee the prevention of an infinite loop.

The retrieved data array is organized into a card-like interface separated by matches, displayed hierarchically. The first element (index 0) stores the entire matched string, and subsequent elements are assigned extraction results as Group 1, Group 2, etc.

If an optional match has no extraction target, it is explicitly shown as (empty) on the screen. With this design, the result display properly verifies the operation of patterns that extract multiple data points.

The specification of flags, which significantly changes the behavior of regular expressions, is designed to be flexibly modified from the input field in this tool.

The tool explicitly permits only 6 types of flags: g (global), i (ignore case), m (multiline), s (dotAll), u (unicode), and y (sticky).

Internally, before generating the regular expression object, a sanitization process filters out any other flags. Any duplicated flags are kept, which will cause a constructor error, and the d and v flags are completely unsupported.

In addition, 4 types of preset samples (Japanese postal code, email, Japanese phone, IP address) containing combinations of patterns, flags, and test text are provided for validation requirements frequently used in daily development.

These samples are loaded with the gm flag applied by default so that applicable strings can be comprehensively extracted from multi-line text data.

The patterns provided as presets, such as email (^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$) and IP address (^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$), are provided strictly as general format examples for learning and confirming syntax.

They do not guarantee the existence check of real domains or the validity of the numerical range of an IP address. Users can use these samples as a starting point to customize patterns tailored to their own requirements.

Because this tool is designed prioritizing lightweight operation and clarity on the client side, several technical limitations exist.

The proprietary simple parsing engine responsible for breaking down the notation does not cover all advanced syntax. For example, when advanced syntax elements like lookbehinds, named capture groups, Unicode property escapes, or complex nested character classes are input, the parsing engine cannot accurately divide them into semantic tokens.

However, separate from this token explanation, the match test itself is executed directly by the browser's JavaScript RegExp engine.

When verifying practical patterns, it is recommended to test small, non-sensitive text examples and check the effects of flags and capture groups one by one.

If you plan to port the regular expression to other engines, you must verify the behavior in that specific environment separately.

From a performance perspective, this tool does not employ Web Workers. If an extremely large test text is input, or if an inefficient regular expression requiring exponential evaluation time is executed, the browser's main thread may be blocked.

The tool is a utility focused on verifying combinations of moderate length.

Although the token breakdown explanation for advanced syntax may sometimes be inaccurate, this visualization is distinct from the actual match results executed by the engine.

For practical use, it is recommended to test with small, non-sensitive examples, confirming the behavior of flags and capture groups one by one.

If you intend to port the regular expression to other language engines, you must verify the behavior separately in those target environments.

For safe utilization, zero-width matching with the Unicode u flag advances by 2 code units across surrogate pairs, and matches are executed inside a Web Worker limited by a 1,000 ms deadline alongside pattern and text size caps.

When limits are exceeded, a notification is displayed, and previous matching requests are terminated upon configuration change or navigation.

Lastly, the matching results provided by this tool are strictly for pattern confirmation and do not guarantee the validity or security of the data in your actual application.