Regex Match Game — Free HTML CSS JS Snippet

The hard part of regular expressions is never writing something that matches — it is writing something that matches the right things and nothing else. A pattern that passes your three examples and quietly also matches half your production data is the classic regex bug, and it is invisible if you only ever test the positive cases. This snippet is a playable trainer built around that exact tension: every level gives a list of strings the pattern must match and a second list it must reject, and a level is only cleared when both lists are fully satisfied.

Grading against string sets, not a stored answer

There is no reference pattern anywhere in the level data. Each level is defined purely by its yes and no arrays, and grading runs the player's compiled RegExp against every string in both lists with re.test(s), requiring true for every positive and false for every negative. That means any pattern satisfying the specification passes — on the file-extension level, \.(png|jpg)$, \.(jpe?g|png)$ and other equivalent formulations are all accepted. Because the specification *is* the test set, the game teaches the habit of thinking about a regex in terms of what it accepts and rejects rather than in terms of a memorised incantation.

Compiling user input without letting it break the page

compile() wraps new RegExp(pattern) in try/catch and returns null on failure, because a half-typed pattern like [a- or (png| throws a SyntaxError on nearly every keystroke while the player is composing. Returning null lets callers distinguish three states cleanly — empty input, invalid syntax, and a usable expression — so the input can show a red border mid-typing without clearing the result marks or spilling errors into the console. The input is also length-capped in the markup, which keeps a pathological pattern from being pasted in wholesale.

Live per-string verdicts on both columns

paint() walks a list, tests each string, and applies a pass or fail class based on whether the actual result equals the *desired* result for that column — so in the left column a match is a pass, and in the right column a match is a failure. Each row also prints the raw verdict ("match" or "no") next to the string, which separates the two things a learner needs to see at once: what the regex did, and whether that was what the level wanted. Because both columns are repainted on every input event, a player watches strings flip between columns' pass states character by character as the pattern is built.

Failure messages that name the direction of the error

When a submission is not perfect, the status line compares the two column scores and reports the specific failure mode: "too strict" when every negative is correctly rejected but some positives are still unmatched, "too loose" when every positive matches but some negatives matched too, and a plain score when both columns have problems. Too-loose is the regex bug that matters most in real code, and naming it explicitly — rather than saying "wrong" — is what turns a wrong answer into a lesson about over-broad patterns.

Levels as a progression of concepts

The seven levels move through literal substrings, character classes, the + quantifier, the ^ start anchor, the \d digit shorthand, alternation with an escaped literal dot and the $ end anchor, and finally a both-ends-anchored email-shaped pattern. Each carries a one-line hint explaining the technique rather than giving the answer, and the negative lists are chosen adversarially — level four rejects "blog", "catalog" and "analogue" specifically so an unanchored log fails and the player has to discover ^.