Regex Cheat Sheet & Tester

Regular expressions ("regex") are tiny domain-specific languages for describing patterns in text. A pattern like \b\d{3}-\d{4}\b describes "three digits, a hyphen, four digits, as a whole word." Once written, regex engines built into PHP, JavaScript, Python, Java, Ruby, Go, Rust, and every modern command-line tool can find, validate, split, or replace text matching that pattern at high speed. For developers, regex is the difference between writing thirty lines of string-walking code and writing one line that does the same job, faster.

Where regex shines

Anywhere you would otherwise hand-write a parser for a small, flat format. Validating that an email looks roughly right, pulling every URL out of a markdown file, splitting a phone number into country code and local digits, finding UUIDs in a log, redacting NRICs before a log leaves the building — all one- to three-line regex problems. The library above holds 82 patterns so the common ones do not have to be reinvented each time.

Where regex stops being the right tool

The classic example is parsing HTML or JSON with regex. These languages are nested, and regex (with the textbook computer-science definition of "regular") cannot match arbitrarily nested structures. Real-world engines like PCRE add features that bend the rule — backreferences, recursive subpatterns — but the maintainability cost is enormous. If you find yourself writing more than 60 characters of regex for a single pattern, or nesting capture groups three levels deep, stop and use a proper parser. DOMDocument in PHP, BeautifulSoup in Python, cheerio in Node — they exist for a reason.

ASEAN-specific patterns

Most published regex collections assume US or UK formats, so the library carries a regional set: Singapore NRIC, postal code, phone and GST registration number; Malaysian IC; Indonesian KTP and phone; Philippine mobile; Thai citizen ID.

Every one of them checks shape, and shape is weaker than it looks. A Singapore NRIC ends in a check letter derived arithmetically from the digits, so [STFGM]\d{7}[A-Z] accepts twenty-five wrong letters for every right one. A Singapore postal code is six digits, but the first two are a sector code and not all pairs are allocated, so \b\d{6}\b also matches any other six-digit run in your text. An Indonesian KTP number encodes province, regency, district, date of birth and sex; \b\d{16}\b knows none of that. A credit-card number has a Luhn checksum the loose pattern does not compute. Use these to find candidates — in a redaction pass, an extraction, a first-pass form hint — and validate properly afterwards. A regex that reports a malformed ID as valid is worse than no check, because it ends the enquiry.

Three ECMAScript rules worth knowing before you debug

\d is exactly ten characters, and u does not change that. ECMA-262 defines it flatly: CharacterClassEscape :: d — Return the ten-element CharSet containing the characters 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9. There is no unicode-aware variant. /\d/u.test("٣") is false for the Arabic-Indic three, with or without the flag. This differs from Python 3 and .NET, where \d is unicode-aware by default — so a pattern ported between them does not mean the same thing.

\w and \b are ASCII, which is why accented text breaks them. The spec builds both from the ASCII word characters, adding others only in the narrow case of the unicode and ignore-case flags together. In practice: /\bcafé\b/ does not match café, and "café".match(/\w+/g) returns ["caf"] — it stops at the é. For real-world text use a Unicode property escape such as \p{L} with the u flag.

A global regex carries state between calls. With g (or y) set, the object remembers a lastIndex and the next .test() or .exec() resumes from there — so the same regex object tested twice against the same string alternates true and false. It is the reason a shared module-level const RE = /…/g produces bugs that only appear on the second call. Either build the regex where you use it, or reset lastIndex yourself.

When regex is the wrong tool

Three signals to stop and reach for a parser: you are matching balanced delimiters at arbitrary depth, you are pulling structured data out of HTML or JSON, or the pattern no longer fits on a screen. Regex is excellent at flat patterns and fragile at grammars — and the fragility is not only about correctness, as the backtracking facts below show.