/^/
MediumWeb5 min read

CSS Comment Regex

Detects a CSS comment, /* ... */, using a lazy quantifier so the match stops at the first closing */ instead of spanning all the way to the last one in the stylesheet.

#css#comment#web#stylesheet#lazy-matching

Regex Pattern

/\*[\s\S]*?\*/

Pattern Breakdown

Hover over a token to see what it does.

/\*[\s\S]*?\*/
TokenMeaning
/\*The literal opening delimiter of a CSS comment: a forward slash followed by an escaped literal asterisk
[\s\S]A character class matching any character at all, including newlines, since plain . does not match line breaks
*?A lazy quantifier: match as few characters as possible while still letting the rest of the pattern succeed
\*/The literal closing delimiter: an escaped asterisk followed by a forward slash

Detailed Explanation

What it does

This pattern finds a CSS comment anywhere in a string, from /* to the nearest following */, correctly handling comments that span multiple lines because [\s\S] matches newline characters as well as everything else.

Why it works

CSS only supports block comments (/* ... */), never line comments, so the pattern only needs one delimiter pair. [\s\S]*? is the standard 'match anything, lazily' trick since . cannot match \n without a dotAll flag. Using the lazy *? instead of a greedy * is critical: a greedy version would consume as much as possible and then backtrack only until it finds the LAST */ in the stylesheet, incorrectly merging multiple separate comments (and any real CSS rules between them) into a single oversized match.

Common use cases

  • Stripping comments from a CSS file as part of a minifier or build pipeline
  • Extracting documentation notes or TODOs written inside CSS comments for tooling
  • Validating that a CSS snippet's comments are properly closed before saving or linting it
  • Removing comments before running further regex-based analysis on selectors or property values

Edge cases

  • A comment spanning multiple lines, like /* line one\nline two */, matches correctly because [\s\S] includes \n
  • An empty comment, /**/, still matches since *? allows zero characters between the delimiters
  • An unterminated comment with no closing */, like /* oops, correctly fails to match
  • Two separate comments back to back, /* a *//* b */, are correctly matched as two distinct comments when using the global flag, because the lazy quantifier stops each match at its nearest */ instead of swallowing through to the final one

Limitations

  • Does not understand CSS string literals, so a /* sequence inside a quoted string value would still be treated as a comment start
  • Cannot safely process CSS containing url() values or attribute selectors with special characters without a real CSS parser
  • Regex-based comment stripping is a lightweight tool, not a substitute for a full CSS tokenizer in a production build pipeline

Interactive Tester

Edit the pattern or text below — matching runs live in your browser.

/* comment */ /* multi line comment */ /**/
3 matches

Test Cases

Editable — add your own inputs to see if they pass.

InputExpectedResult
Pass
Pass
Pass
Pass
Pass
Pass
Pass

Language Variants

Production-ready examples in 12 languages.

const cssCommentRegex = /\/\*[\s\S]*?\*\//;
console.log(cssCommentRegex.test('/* padding */')); // true

// Strip all comments (lazy quantifier keeps each match isolated)
const stripped = 'a{}/* note */b{}'.replace(/\/\*[\s\S]*?\*\//g, '');

Common Mistakes

Using a greedy quantifier, /\*[\s\S]*\*/, which spans from the first /* all the way to the LAST */ in the file, merging multiple separate comments and any real CSS between them into one match

Fix: Use the lazy quantifier *? so matching stops at the nearest closing */ instead of the farthest one

Using . instead of [\s\S] and forgetting it does not match newlines by default, so multi-line comments silently fail to match

Fix: Use [\s\S] (or enable a dotAll/singleline flag where the engine supports it) so the match can span line breaks

Forgetting to escape both the forward slash and the asterisk, writing an invalid or wrong pattern like /*.*?*/

Fix: Escape the asterisks as \* (and the slash if the regex delimiter itself is '/') so they are treated as literal characters, not quantifiers

Performance Notes

  • The lazy *? quantifier may backtrack more than a greedy * on pathological inputs with many stray asterisks, but remains linear for typical stylesheets
  • Prefer a global-flag replace/matchAll pass over a stylesheet once, rather than re-running the regex per line
  • For large codebases, a real CSS tokenizer in a build tool (PostCSS, Sass compiler) is more robust than ad-hoc regex stripping

Browser Compatibility

EngineSupportedNotes
ChromeYes
FirefoxYes
SafariYes
EdgeYes
Node.jsYes