AiCoN

Home / Posts / regex101

CHECK BEFORE SHIPPING
Actual regex101 editor showing two matches among six fictional invoice ID cases
Actual tool screenshot, checked 29 October 2026. Fictional inputs. This is a screenshot, not a logo.

regex101: test the pattern before you trust it

By AiCoN | Published 29 October 2026 | Sources checked 29 October 2026

An AI-generated regex can look right and still accept the wrong input. regex101 runs the pattern against examples and shows exactly which text matched. We tested a simple invoice-ID rule with two intended matches and four deliberately wrong cases, rather than trusting the pattern's appearance.

Quick facts

Why use it beside a chatbot?

A chatbot can suggest a regex and explain its intent. A regex tester executes it in a selected engine and highlights actual matches. That gives you a concrete way to challenge the suggestion with wrong-length values, prefixes, lowercase text and other edge cases. It is a verification step, not proof that a rule is complete or safe in production.

Our six-case check

On 29 October 2026 we entered this pattern in the real public editor using PCRE2 (PHP) and gm flags:

^INV-[0-9]{4}$

We wanted uppercase INV-, followed by exactly four ASCII digits, across one test string containing these six lines:

INV-1234
INV-0007
INV-12
inv-1234
INV-12345
xINV-1234

The editor returned two matches: INV-1234 and INV-0007. The shorter ID, lowercase prefix, extra digit and extra leading character were not matched. Match Information showed offsets 0-8 and 9-17 for the two accepted values. Those results matched our expectations for this sample.

This is a fictional format check, not an invoice verifier. It says nothing about whether an invoice exists, whether a customer owes money or whether a number is unique.

Repeat the useful part

  1. Open regex101 and choose the engine your real application uses. Our check kept PCRE2 (PHP).
  2. Paste the pattern into Regular Expression and fictional examples into Test String. Include both cases that should match and cases that should fail.
  3. Inspect flags. In our check g finds all matches and m makes ^ and $ apply to each line. We did not enable case-insensitive matching.
  4. Compare the actual match list with your expected list. Do not judge a pattern only by whether the first happy-path example matches.
  5. Run equivalent tests in your actual application before shipping. For a single-value field, use your engine's full-match or appropriate anchoring approach rather than copying this multiline harness blindly.

Small choices change the result

The same visible pattern can behave differently across engines, flags and newline conventions. Here, m is intentional because the test input has one ID per line. It is not a universal setting for form validation. We used [0-9] to express ASCII digits explicitly. This six-line check did not cover trailing spaces, Unicode, every newline type, long inputs or performance risks.

The official comparison says Free includes two editable test strings and unit tests. We used one multiline test string, not six separate tabs, and did not run the unit-test interface. Advanced benchmarking and other Pro tools were not part of this check.

Keep private data out of sharing links

The privacy guide separates browser processing from saving and sharing. It says matching and editor operations run on your device, but saving or publishing a workspace sends its pattern, test strings and other saved fields to regex101. Copy draft link places editor content in the URL, readable by whoever receives it. Use invented examples for public links and do not paste passwords, tokens or customer records into a demonstration.

We did not audit network traffic, test offline operation, create an account or test hosted workspace permissions.

Sources