sed regex tester — POSIX BRE, where ( ) and { } are literal and \( \) \{ \} do the work

A bare sed 's/pattern/replacement/' — no -E, no -r — and a bare grep 'pattern' file both run POSIX Basic Regular Expressions, and BRE is the one flavor on this page where the grouping and quantifier metacharacters are inverted from literally every other engine here. In every Perl-family flavor and even in POSIX ERE, ( ) create a group and { } write a quantifier. In BRE, ( ) and { } are plain literal characters, and it's the backslashed forms — \( \), \{ \} — that create a group or an interval quantifier instead.

This single inversion is the most common reason a sed one-liner "doesn't work" the first time someone writes it: a pattern like (abc){2} written with ERE or Perl instincts matches the literal eight-character string "(abc){2}" under bare sed, not two repetitions of "abc" grouped together. The working BRE equivalent is \(abc\)\{2\}. It looks unfamiliar the first several times, and it is exactly why the -E flag (or -r on GNU sed, both work identically on modern GNU systems) exists — it switches sed to ERE, where the more familiar unescaped ( ) and { } apply.

| for alternation, + for one-or-more, and ? for zero-or-one are not real metacharacters in strict POSIX BRE at all — a bare | in a BRE pattern matches a literal pipe character. GNU grep and sed extend BRE with \|, \+ and \? as GNU-specific extensions carrying the ERE meaning, and that extended behavior is what this flavor models, because it's what actually ships and what nearly every BRE pattern anyone writes today assumes. A strictly conforming, non-GNU sed (some BSD and embedded systems) will not accept \| at all, which is worth checking if portability beyond Linux matters for a given script.

Backreferences work here exactly as in ERE: \1 through \9 reference the \( \) groups in source order, which makes BRE — despite its unfamiliar bracket-escaping — strictly more capable in one specific way than RE2 (the engine behind Go and ripgrep's default mode), which has no backreferences at all. A pattern like \(.\)\1 (match any character immediately followed by itself) is valid, working BRE syntax.

Matching itself follows the same POSIX leftmost-longest rule as ERE, not the leftmost-first rule every Perl-family engine on this page uses — the same (a|ab)-against-"ab" divergence covered in the grep -E guide applies here too, just spelled \(a\|ab\) once you're using the GNU \| extension instead of bare |.

The s command's own delimiter is a separate, easy-to-forget escaping layer on top of the pattern itself: s/pattern/replacement/ uses / as the field delimiter, so a literal / inside the pattern or replacement needs \/ — or, more cleanly, sed lets you pick a different delimiter entirely, s|pattern|replacement| being the common choice when the pattern is a file path full of slashes. That delimiter choice is orthogonal to BRE-versus-ERE, but it's the second most common reason a sed one-liner someone pasted from a forum doesn't run as written against a path-like input.

The replacement side of an s/// command has its own small syntax, separate from BRE itself: & stands for the whole match (not $& the way JavaScript or .NET spell it), and GNU sed adds \U, \L and \E to upper-case, lower-case, or stop transforming the text that follows, entirely absent from the POSIX standard but present on essentially every Linux system's sed. A replacement of \U&\E upper-cases whatever the pattern matched — a small, GNU-only convenience that has no equivalent at all in strict POSIX BRE or ERE's replacement rules, and is worth checking for before relying on it in a script meant to run on BSD or a minimal container image's sed.

Matching capture behavior under leftmost-longest carries into the s command too: because BRE's captures are POSIX subexpressions rather than Perl-style ordered alternatives, a backreference-heavy substitution can extract a different, longer piece of text than the leftmost-first intuition from JavaScript or Python would predict for the identical-looking pattern — one more reason to verify a nontrivial sed substitution here, against this tool's genuine POSIX matching mode, before trusting it against production data.