Regular Expressions (Regex) for Beginners

Step 1. The developer’s pattern [A-Z]{2}\d{9}[A-Z]{2} has two defects, one in each direction of the guide’s list of mistakes. It matches too much because it has no anchors: it accepts any input that contains a valid number somewhere, so XRB123456789SAX, RB123456789SA123 and RB123456789SA with a trailing space all pass. It matches too little because [A-Z] without the i flag rejects rb123456789sa, which FR-21 says the form must accept. Corrected pattern: ^[A-Z]{2}\d{9}[A-Z]{2}$ with the i flag, written /^[A-Z]{2}\d{9}[A-Z]{2}$/i in JavaScript; ^[A-Za-z]{2}\d{9}[A-Za-z]{2}$ without flags is equivalent. One caution before you report the second defect: if the form converts the input to upper case before this check runs, lower-case letters already pass. That is a question for the developer, and the test input rb123456789sa settles it either way.

Step 2. Must match: RB123456789SA, rb123456789sa (case) and CP987654321IN (another prefix and country). Must not match: RB12345678SA (8 digits) and RB1234567890SA (10 digits), the two boundary lengths; RB123456789S (a single trailing letter); R1123456789SA (a digit where a letter must be); XRB123456789SAX and RB123456789SA123 (extra characters, which only the anchors reject); RB123456789SA with a trailing space (common after copy and paste); RB-123456789-SA (separators); and an empty input. Each invalid input breaks exactly one part of the rule, so when one of them is accepted you know which part of the pattern is wrong. The expected result for every input is "accepted" or "rejected", as in any validation test case.

Step 3. One pattern that satisfies FR-22: ^Parcel (?<id>[A-Z]{2}\d{9}[A-Z]{2}): (?<status>accepted|in transit|out for delivery|delivered) (?<date>\d{4}-\d{2}-\d{2}) (?<time>\d{2}:\d{2}) \((?<city>[^()]+)\)$. The points that matter: the alternation for the status sits inside its own group, so its scope is only the status; written without the group, accepted|in transit|… would split the whole pattern into four alternatives and match almost any text that contains "in transit". The parentheses around the city are metacharacters, so the literal ones are escaped as \( and \). The city is [^()]+ rather than \w+: \w+ matches "Riyadh" but not "New Delhi" because of the space, and, as the guide warns, never an Arabic or Devanagari city name if the page is localised; a negated class, or [\p{L}\p{M} ]+ with the u flag, handles both. The anchors ^ and $ make the check reject a line with anything missing or added. On the first example line the groups are id = RB123456789SA, status = delivered, date = 2026-10-02, time = 14:05 and city = Riyadh; on the second, status = out for delivery and city = New Delhi. A line with "delivred" does not match at all, so the check fails instead of reporting a pass, which is exactly what a test needs: a loose pattern that accepts a wrong value makes the test pass when it should fail (a false-negative result). In the test, compare each group with the expected value, for example m.groups.status === "delivered". The date group \d{4}-\d{2}-\d{2} is enough here because the test compares the value itself; use the stricter ISO date pattern from the guide only when the purpose of the test is the format. In the automated check the pattern runs on one status line and needs no flag; to try it in the Regex Tester against the whole material, turn on the m flag, for the reason explained in step 4.

Step 4. A pattern that finds only the two 5xx responses on parcel paths: ^\S+ \S+ /api/v2/parcels(?:/\S*)? 5\d\d \d+ms$ with the m flag, so that ^ and $ match at line boundaries, and the g flag in the tester to see every match; in a JavaScript regex literal the slashes are written \/. Read from left to right: the timestamp, the method, the path /api/v2/parcels optionally followed by / and more non-space characters (/RB123456789SA or /RB123456789SA/events), a status that starts with 5, and the duration. It matches exactly two lines: the GET with 503 and the POST with 502. 5\d\d on its own finds nine matches on six of the seven log lines, because it finds digits anywhere: 567 inside RB123456789SA on two lines, 512 and then 567 inside CP512345678IN, 512 again in the duration 512ms, 500 inside EE500000000SA, and the 500 on /api/v2/rates, which is not a parcel path; only the 503 and the 502 are the responses you want. A space on each side of the status, \s5\d\d\s, removes the false matches in tracking numbers and durations but keeps the rates line; the path condition removes that one too. Without the m flag the pattern matches nothing, because ^ and $ then mean the start and the end of the whole text. It is the same rule as in the form: without context and anchors a regex matches too much.

Step 5. Open questions for the product owner or the developer: does the form validate before or after converting to upper case, and is the input trimmed (a trailing space from copy and paste is common)? Should digits typed on an Arabic keyboard as Arabic-Indic digits be accepted or converted? \d in JavaScript matches only 0–9, so RB١٢٣٤٥٦٧٨٩SA is rejected. Is the status list in FR-22 complete, and what does the line look like when a parcel has no city yet? And which error message does the form show for each rejected input, so that the test can assert it?

If your patterns differ, check them in the Regex Tester. The form pattern, tried on each step 2 input (or on all of them, one per line, with the m flag), must accept the three valid inputs and reject all the others. Against the material with the m flag, the status-line pattern must match the three status lines with the right group values, and reject the misspelled line when you add it, and the log pattern must highlight exactly two log lines. A different but equivalent pattern is fine — \d{2} and [0-9]{2} are the same — as long as it is anchored where it validates, escapes every literal metacharacter and keeps the alternation inside a group. None of these patterns puts a repeating quantifier on a group that contains one, like (a+)+ in the guide: the only quantified group, (?:/\S*)?, is optional and runs at most once, so the risk of catastrophic backtracking is low; paste a long input to be sure. Then put the status-line pattern into the Regex Explainer and read it token by token: it is a quick way to find a mistake you cannot see.