Why format a regex at all?

A pattern like this ships in real projects every day:

^(?<section>\[(?:[A-Za-z0-9_.-]+)\])|^(?<key>[A-Za-z_][A-Za-z0-9_]*)\s*=\s*(?<value>"(?:[^"\\]|\\.)*"|'(?:[^'\\]|\\.)*'|[^#\n]*)\s*(?:#.*)?$

An INI-line parser: a section header or a key–value pair, three quoting modes for the value, trailing comments. Perfectly readable — to the person who wrote it, today. Come back in three months, or hand it to a teammate, and the review comment is always the same: what does this actually match?

Formatting solves this the way it's solved for every other language. The same pattern, laid out by structure:

^ (?<section>[(?:[A-Za-z0-9_.-]+)])
| ^ (?<key>[A-Za-z_][A-Za-z0-9_]*) s* = s*
(?<value>
  "
  (?:
    [^"\]
  | \ .
  )*
  "
| '
  (?:
    [^'\]
  | \ .
  )*
  '
| [^#
]*
)
s* (?:#.*)? $

Two branches instead of one buried |; three quote styles you can point at; a comment-stripping tail that's obviously a tail. Same language — the difference is purely typographic, which is exactly the point.

A 60-second tour

The entry point is the Format button on the tester toolbar — next to Debug and Bench, right where you're already working. There's also a deep link at /format that opens the tester with the formatter ready, so you can bookmark it or send it to whoever inherits your patterns.

Hit it and the formatter parses the pattern immediately. The demo below is the INI parser from the previous section — 116 characters on one line in the editor, 18 structural lines in the panel. Short groups that read fine inline stay inline (the threshold is adjustable); anything with an alternation inside expands so the branches can be stacked; a quoted-string group with nested alternation gets the full treatment.

The left column holds the style decisions: indent unit (2 spaces, 4 spaces or tabs), how wide a group may get before it's expanded, where wrapped lines break, whether tokens are separated by spaces, whether branches get a blank line between them. The output on the right updates live as you move any control, and your choices persist between sessions.

Three modes: Pretty, Annotated, Minify

Pretty

Pure structure, no commentary — the form you merge into source code. Whitespace between tokens is inserted where it helps (\s* = \s* instead of \s*=\s*), everything else is layout.

Annotated

The same layout plus inline # comments derived from the parsed syntax tree — not canned strings. Capturing groups are numbered in the order the engine assigns them, named groups carry their name, and constructs that merely look similar get distinguished: a lookahead says it asserts ahead, an atomic group says it refuses backtracking, a conditional says what it is.

Because the comments come from the AST, they're dialect-aware: the same (?<name>…) is an ordinary named capture everywhere, but a (?'name'…) only exists in flavors that support that spelling, and the annotations follow what your selected flavor actually allows. Use it as documentation for the review thread, the wiki page, or your future self.

Minify

The reverse operation, for when you need the opposite direction: paste a sprawling free-spacing pattern from a config file or a codebase and get the compact one-line equivalent. Minify strips whitespace and # comments — outside character classes and escape pairs, which are exactly the places free-spacing mode treats as significant — and leaves every other byte alone.

Minify is honest about its limits: if the x flag is off, it warns that the pattern's whitespace is currently significant and shouldn't be stripped — that's the one case where “removing whitespace” would change meaning.

Why the layout can't change behavior

Reformatting working regex is scary for one reason: whitespace is a construct in regex. A space can be a required literal, a token separator you'll never see, or — under free-spacing mode — nothing at all. A formatter that guesses wrong doesn't make your pattern uglier, it makes it match something else.

So this formatter is built on a rule it cannot violate: every token is copied verbatim from the source pattern, straight from the parser's token spans. The formatter only ever inserts whitespace, newlines and comments between tokens — which is precisely the category of bytes free-spacing mode ignores. Three consequences fall out of that rule:

• A literal space in your pattern becomes \ (or \t, \n, …) in the output, so free-spacing mode can't eat it.
• A literal # becomes \#, so it can't start a comment.
• Character-class interiors are left completely untouched — whitespace inside […] is significant even under x mode, so the formatter never adds, removes or wraps anything there.

The same scanner powers Minify in reverse: it only removes the byte categories free-spacing mode ignores, and it walks the text with the same class- and escape-awareness so an escaped space or a class containing a b#c survives intact.

Verified, not assumed

“Trust me, the layout is safe” is not a review argument, so the panel shows its work at the bottom of every run:

Round-trip proof. The formatter re-minifies its own output and compares it, byte for byte, with the escaped input. If the only difference between your pattern and the formatted text is whitespace and comments outside classes — exactly what x mode ignores — the green Round-trip exact line appears. Any other difference turns the line red and tells you to check the parse errors above.

Live behavior check. Static proof covers the text; the dynamic check covers the meaning. Both forms — original and formatted, the latter with the x flag enabled — are executed against your current test string on the real engine for your flavor, and every match is compared: text, position, and each capture group's content. Only identical match lists earn the green Behavior verified line; any divergence is flagged as a mismatch you should investigate before trusting the output.

And when the browser doesn't support the x flag yet, the panel says so explicitly instead of pretending — the round-trip proof still applies, and Apply falls back to inserting the compact equivalent so the editor never receives a multi-line pattern the runtime would misread.

Your dialect's x mode, handled

Free-spacing is spelled differently everywhere: the x modifier in PCRE, re.X / re.VERBOSE in Python, Pattern.COMMENTS in Java, IgnorePatternWhitespace in .NET, and the newly standardized x flag in ES2025 JavaScript. The formatter knows which flavor you're on and shows the right way to enable it — including the inline (?x) and scoped (?x:…) forms where they apply.

Flavors without any free-spacing mode get told that too, clearly, instead of being handed a multi-line pattern that would silently change meaning: for those, the panel points you at Minify or suggests keeping the annotated output as documentation next to the one-line pattern. Parsing, annotations and suggestions are all dialect-aware across the nine flavors the tester supports.

How it compares

Regex formatters exist — usually as structure-only re-layouts of a single flavor, usually without any check that the result still matches, and not rarely behind a paid subscription. This one was built against that bar:

Also in the box: live stats (lines, width, depth), session-persistent style options, and the /format deep link.

FAQ