{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
Regex sample contract setup
Pattern and expected sample behavior
Use JavaScript regular-expression syntax, for example ^[A-Z]{3}-\d{4}$.
Enable only the JavaScript flags required by this sample contract.
Choose whether a substring hit is enough or every sample must be consumed completely.
Pick how copied fixture whitespace should affect the contract.
One expected-match sample per line.
One expected-reject sample per line.
Changes the fixture lists; the current pattern and flags stay in place.
{{ summaryAnnouncement }}
Rows above the cap are named in the failure brief.
rows
Total characters across both sample lists.
chars
Only the recorded evidence size changes.
matches
{{ verdictExportStatus }}
SetLineSampleExpectedActualVerdictFirst spanCopy
{{ row.setLabel }}{{ row.source_line }}{{ row.sample }}{{ row.expectedLabel }}{{ row.actualLabel }}{{ row.passed ? 'Pass' : 'Fail' }}{{ row.spanLabel }}
{{ chartExportStatus }}
{{ briefExportStatus }}
SignalStatusDetailCopy
{{ row.signal }}{{ row.status }}{{ row.detail }}

A regular expression becomes trustworthy only after it has been challenged with examples that must match and near misses that must not. One successful search proves very little: an unanchored pattern can accept a valid fragment inside an invalid line, and a convenient flag can quietly widen the accepted text.

A sample contract turns that uncertainty into repeatable evidence. Positive fixtures describe the intended language of the pattern. Negative fixtures mark nearby boundaries such as wrong case, extra digits, missing separators, leading spaces, or unwanted suffixes. Every change to the expression can then be checked against both sets.

False negative
A line that should match does not match.
False positive
A line that should be rejected contains a match.
Whole-line match
The complete sample must satisfy the expression, not merely contain a matching substring.

Fixture coverage is still bounded by the examples chosen. Passing samples do not prove that a pattern is correct for all possible input, and they do not make an inefficient expression safe for untrusted or very large text. Keep production tests in the same regular-expression engine and add a regression fixture whenever a real failure is found.

How to Use This Tool:

Define the matching contract before tuning the expression so a change cannot make one fixture pass by breaking another.

  1. Enter a JavaScript Pattern and enable only the flags required by the intended runtime.
  2. Choose Any regex hit passes for search behavior or Whole line must match when the entire fixture is a record.
  3. Add one positive fixture per line under Should match, then add close counterexamples under Should not match.
  4. Choose whether line-edge whitespace is trimmed or preserved, then read Sample verdicts. Fix every missed positive and unexpected negative match before accepting the pattern.

Interpreting Results:

A passing contract means every retained positive sample produced at least one match and every retained negative sample produced none. The verdict is limited to those samples, the selected flags, the line handling, and the match rule.

  • A missed positive points to an expression or flag that is too narrow.
  • An unexpected match in the reject set points to an expression that is too broad; inspect the first recorded span to see which fragment was accepted.
  • Blank lines are ignored. A row-cap warning means later fixtures were not evaluated, and positive rows consume the cap before negative rows.
  • An evidence-cap warning limits recorded spans for that sample. It does not turn a failing fixture into a pass.

Technical Details:

Each non-blank sample line is compiled and evaluated with JavaScript regular-expression semantics. The outcome is Boolean: a positive fixture passes when at least one match exists, while a negative fixture passes only when no match exists.

Rule Core:

  1. Remove carriage-return differences and either trim each line edge or preserve the line exactly.
  2. Ignore blank lines and retain rows up to the active cap, taking positive fixtures first.
  3. Normalize flags into the order dgimsuvy, reject unsupported flags, and reject the incompatible u plus v combination.
  4. For whole-line mode, evaluate the equivalent of ^(?:pattern)$; otherwise evaluate the pattern unchanged.
  5. Compare the presence of a match with the fixture's expected result and aggregate the pass and failure counts.
Supported JavaScript regular expression flags
FlagMeaningPractical effect
dMatch indicesAdds index data to JavaScript match objects.
gGlobalCollects successive matches up to the evidence cap.
iIgnore caseMakes case differences eligible to match.
mMultilineChanges the meaning of line anchors in multiline text.
sDot allAllows a dot to match line terminators.
uUnicodeUses Unicode-aware pattern and index handling.
vUnicode setsEnables Unicode set notation and Unicode-aware handling.
yStickyRequires each search to begin at the current match position.

Global and sticky expressions advance by one Unicode code point after an empty match so repeated evidence collection cannot remain at the same position. Without either flag, only the first span is recorded because the pass/fail decision needs only one hit.

Validation Boundaries:

Regex checker input limits and guard behavior
InputAccepted rangeFailure behavior
Pattern1 to 1,000 charactersBlank, oversized, or invalid JavaScript syntax is rejected.
Sample rows1 to 1,000 retained rowsRows above the selected cap are reported as skipped.
Combined fixture text1,000 to 200,000-character configurable limitThe contract is withheld when the combined text exceeds the active limit.
Evidence per sample1 to 100 spansAdditional spans are not recorded after the active cap.

A preliminary guard rejects recognizable nested-quantifier and repeated-wildcard shapes associated with excessive backtracking. That narrow check is not a runtime proof and does not cover every expensive regular expression.

Privacy and Safety Notes:

Patterns and fixtures are evaluated in the browser. Avoid pasting confidential production data when synthetic fixtures can express the same boundary.

  • Use the same JavaScript engine and flags as the deployed code before treating the contract as release evidence.
  • Do not run an accepted pattern against unbounded attacker-controlled text without separate performance testing and execution limits.
  • Keep both positive and negative regression fixtures with the code that consumes the expression.

Worked Examples:

Asset code boundary

The pattern [A-Z]{3}-\d{4} finds a valid fragment inside OPS-20260, so that reject fixture fails in any-hit mode. Whole-line mode wraps the expression with anchors and rejects the extra digit.

Whitespace-sensitive record

A fixture copied as ABC-1234 passes when line edges are trimmed. Preserving exact line text makes the spaces part of the sample, which is the correct test when fixed-width or deliberately padded input matters.

References: