Regex Tester

How regular expressions work

A regular expression is a compact description of a set of strings. The engine scans your test text left to right, attempting to match the pattern at each position. When it succeeds, it records the match (and any capture groups) and — if the global flag is set — continues from the end of that match. Under the hood, most modern engines compile the pattern into a finite-state machine, which is why even long patterns usually run in linear time. Pathological patterns with nested quantifiers ((a+)+) are the exception: they can trigger catastrophic backtracking, so prefer atomic or possessive quantifiers where your engine supports them.

Common regex use cases

Validation is the classic one: confirming that an email, phone number, or postcode fits an expected shape before it hits your database. Scraping is the opposite direction — pulling prices, IDs, or URLs out of unstructured HTML or text dumps. Log parsing sits in the middle: engineers use capture groups to extract timestamps, severity levels, request paths, and user IDs from millions of lines of server output, then feed those fields into dashboards. Regex is also the workhorse behind find-and-replace in editors, route matching in web frameworks, and tokenisation in lightweight parsers. When a full grammar is overkill but string matching is too blunt, regex is usually the answer.

JavaScript regex quirks vs PCRE

JavaScript's regex engine is close to PCRE but not identical. JS supports lookbehind ((?<=...)) only from ES2018 — fine in modern browsers, but watch older runtimes. There are no possessive quantifiers (a++) and no atomic groups in vanilla JS. Named captures use (?<name>...) and are referenced with$<name> in replacement strings. Unicode property escapes (\p{Letter}) require the u flag. And a subtle one: theg flag makes RegExp stateful via lastIndex, so reusing a global regex inside a loop can produce surprising results unless you reset it or use matchAll instead.