LESS Comments

LESS supports two comment styles: single-line comments borrowed from JavaScript, and traditional CSS block comments. Knowing which one survives compilation matters for anything you intend to keep in production CSS, like a license header.

Line Comments vs Block Comments

Line comments start with // and continue to the end of the line. They are a LESS-only addition, not valid in plain CSS, and are always stripped out during compilation, they never appear in the output CSS.

Block comments use the familiar /* ... */ syntax from CSS and can span multiple lines. Unlike line comments, block comments are preserved in the compiled output (unless the output is minified/compressed).

// This line comment is removed during compilation
@radius: 8px; // inline note, also removed

/* This block comment survives compilation */
.card {
  border-radius: @radius;
}

Only the block comment appears in the final CSS; both line comments are gone after compiling.

Comment Syntax

// line comment, removed from output
/* block comment, kept in output */

Line comments (//) are LESS-only and never valid in plain CSS files.
Block comments (/* */) are valid CSS syntax and are preserved by default.
Minifying/compressing output (--clean-css) strips block comments too, unless marked to be preserved.
Comments can appear anywhere whitespace is allowed: between declarations, selectors, or at the top of a file.

LESS Comments Cheatsheet

Quick reference for comment behavior during compilation.

Comment Type	Syntax	Survives Compilation?
Line comment	`// note`	No, always removed
Block comment	`/* note */`	Yes, kept by default
Block comment (minified)	`/* note */` with `--clean-css`	No, stripped unless marked with `!`
Preserved minified comment	`/! note /`	Yes, `!` marks it as important to keep

When to Use Each Comment Type

Use line comments for internal notes meant only for developers reading the source, explaining why a value was chosen, or leaving a TODO. Use block comments for anything you want to survive into the compiled CSS, like a license header or a note for someone inspecting production styles.

// TODO: replace this magic number once design tokens ship
@legacy-offset: 13px;

/*!
 * MyProject v1.2.0
 * Licensed under MIT
 */

The exclamation mark after /* tells some minifiers to preserve this comment even when compressing.

Documenting Mixins and Variables

Since LESS variables and mixins have no formal documentation syntax, teams typically rely on comments directly above a declaration to explain intended usage, valid argument ranges, or units expected.

// Spacing scale used across all components, values in rem
@spacing-sm: 0.5rem;
@spacing-md: 1rem;
@spacing-lg: 2rem;

// Centers a block-level element horizontally.
// Usage: .center();
.center() {
  margin-left: auto;
  margin-right: auto;
}

Common Mistakes

Using // comments for content meant to survive into the compiled CSS output, like a license header.
Assuming block comments always survive; minified/compressed builds strip them unless marked with /*! ... */.
Leaving large blocks of commented-out dead code in a LESS file instead of deleting it (version control already keeps history).
Forgetting that comments inside a mixin's argument list can sometimes confuse older LESS parser versions.

Key Takeaways

Line comments (//) are always stripped from compiled CSS output.
Block comments (/* */) are preserved by default, but stripped by minifiers unless marked /*! */.
Use line comments for internal notes and block comments for anything meant to reach production CSS.
Well-placed comments above variables and mixins act as lightweight documentation for a team.

Pro Tip

If you need a comment (like a license or build banner) to survive even a minified production build, use the exclamation-mark syntax: /*! Your comment here */.