Regex Sample Matches Checker

A regular expression rarely fails only by refusing to compile. The riskier failure is a pattern that accepts a value with extra characters, misses a valid value after a small format change, or finds a match in the middle of a string that was supposed to be checked as a complete value. That matters for identifiers, log filters, filenames, form validation, migration rules, and any review where one match changes what gets routed, accepted, or rejected.

A sample contract makes the intended boundary visible. Positive examples show the shapes that must be accepted. Negative examples show nearby shapes that must stay out. The negative set often gives the strongest evidence because it catches overmatching: lowercase variants, extra suffixes, missing separators, unexpected whitespace, doubled tokens, and values that look valid at a glance.

Pattern

The text rule itself, such as a literal prefix, a digit count, a character class, or a group of alternatives.

Flags

Options that change how the pattern reads the sample, including case, multiline anchors, dot behavior, Unicode mode, global evidence, indices, and sticky matching.

Anchors

Boundary assertions such as ^ and $ that decide whether a substring can pass or the whole value must satisfy the pattern.

Near miss

A sample that is intentionally close to valid but should fail, such as OPS-20260 when exactly four digits are required.

Substring matching is the common trap. A pattern for [A-Z]{3}-\d{4} can find OPS-2026 inside OPS-20260, which is useful for search but wrong for a complete asset code. Whole-value validation needs anchors or an equivalent full-sample rule so leftover characters cannot hide after a valid-looking token.

JavaScript regular expressions have their own syntax and flag behavior. A pattern copied from another language may need escaping changes, and Unicode-aware matching can change how characters and sets are interpreted. Case-insensitive matching, multiline anchors, and dot-all behavior are especially easy to leave enabled after a test, which can make the sample contract pass for the wrong reason.

Sample testing does not prove a regex is correct for every possible string. It shows how the current examples behave under the selected rule and flags. Performance also belongs in the review because repeated groups, nested quantifiers, and overlapping alternatives can backtrack heavily on crafted nonmatches. A pattern that times out on a small fixture deserves a simpler design before it handles untrusted text.

How to Use This Tool:

Use the checker as a small regression suite for one JavaScript regular expression and one fixture set at a time.

1. Enter the expression in Pattern without surrounding slash characters. The page reports a pattern error if the text or selected flags cannot compile.
2. Select only the Flags needed for the case. The supported set is d, g, i, m, s, u, v, and y; u and v are mutually exclusive.
3. Choose Any regex hit passes for search behavior, or Whole line must match when each sample is one complete value.
4. Set Line handling before pasting fixtures. Trim mode cleans copied lists; preserve mode keeps leading and trailing spaces as part of the sample. Blank lines are ignored.
5. Paste accepted examples in Should match and rejected examples in Should not match, one nonblank sample per line.
6. Use Load sample, Swap sets, or Reset samples when you need a clean fixture, an inverted test, or empty sample lists without changing the pattern.
7. Open Advanced when a large or risky suite needs bounds. The row cap, execution timeout, sample text limit, and per-sample match cap keep the browser check controlled.

Start with Failure Brief when the summary says the contract needs review, then inspect Sample Verdicts for the exact row and match span. Use Sample Outcome Mix for a quick pass/fail distribution and JSON when you need a portable result record.

Interpreting Results:

All samples pass means every positive row matched and every negative row stayed rejected. Add samples means the pattern has no useful evidence yet. Check pattern or Fix pattern means the expression failed to compile, timed out, missed an expected match, matched a reject row, or ran into a guardrail.

The Failure Brief separates pattern compilation, expected matches, reject-set behavior, sample handling, and guard status. That split helps avoid the wrong fix. A missed positive row calls for broader acceptance. An overmatched reject row calls for tighter boundaries or a less permissive flag.

Do not compare two revisions unless the settings match. Changing from any-hit matching to whole-line matching, trimming whitespace, or enabling case-insensitive mode can change the verdict even when the pattern text stays the same.

Technical Details:

JavaScript compiles a regular expression from pattern text plus a flag string. The pattern contributes tokens such as literals, character classes, groups, assertions, alternatives, and quantifiers. Flags change the matching environment: they can collect repeated evidence, ignore case, treat anchors as line-aware, make dot match line breaks, enable Unicode-aware parsing, request match indices, or force sticky searches.

The main contract is simple. A positive sample passes when the selected rule finds at least one match. A negative sample passes when the selected rule finds no match. In whole-line mode, the expression is evaluated as a complete-sample rule, so leftover text before or after the matched token fails the row.

Positive row passes: match exists
Negative row passes: no match exists
Whole-line mode: the full sample must satisfy the pattern
Any-hit mode: a matching substring is enough

Flag Map:

Sample Handling Rules:

Guardrails:

Privacy and Safety Notes:

The pattern and samples are checked in your browser. That keeps the regex test itself local, but the text can still be exposed through normal browser surfaces such as history, copied output, downloaded reports, shared URLs, or extensions. Do not paste secrets, private tokens, production logs, or customer data unless that is acceptable for your environment.

A passing sample suite is not a security audit. It does not prove that the regex is safe against every input length, every runtime, or every engine. Treat timeout warnings and slow nonmatches as a reason to simplify the expression before using it with untrusted text.

Worked Examples:

Asset Code Validator

Pattern ^[A-Z]{3}-\d{4}$, no flags, and Whole line must match accepts ABC-1234, OPS-2026, and NET-0007. Reject rows such as abc-1234, ABCD-123, ABC-12X4, and OPS-20260 stay rejected. The brief shows the positive and negative sets passing.

Missing Anchor Overmatch

Pattern [A-Z]{3}-\d{4} can find OPS-2026 inside OPS-20260 when Any regex hit passes is selected. The reject row becomes Overmatched, and the match span points to the matched substring. Whole-line mode or explicit anchors corrects the boundary.

Case Flag Surprise

Pattern ^[A-Z]{3}-\d{4}$ with the i flag makes abc-1234 match even when uppercase letters are required. Removing the flag is better than changing the character class when uppercase is part of the contract.

Whitespace-Sensitive Input

If a value with a leading space should fail, preserve line text before testing it. Trim mode would remove the line-edge space and could hide the failure. Preserve mode keeps the row closer to the exact input that the regex will see.

Timeout During Review

A pattern with nested repetition can hit the selected Execution timeout on a long nonmatching sample. The right fix is usually to simplify the repeated structure or narrow the input rule, not just to raise the timeout.

FAQ:

References:

• MDN Web Docs: JavaScript regular expressions
• OWASP: Regular expression Denial of Service