LESS Minifier & Beautifier
Format or compress LESS source — @variables, mixins and interpolation all understood. This formats your Less; it does not compile it to CSS.
Only whitespace and comments are ever changed. No LESS token is renamed, reordered or removed, so the output cannot behave differently from your input. That also means the size reduction is smaller than tools which rewrite your code — no variable mangling, no dead-code removal — no merged selectors, no collapsed shorthands — and because SQL needs whitespace between tokens, it can only be collapsed, never removed. This formats your source; it does not compile it. Your types are preserved, not stripped.
/*! banner comment is always kept, the usual
convention for a licence header.
Drop a LESS file here
Up to 4 MB · nothing uploaded
{{ error }}
{{ commentWarning }}
Verified — every token preserved
The output was re-tokenized and compared against the input: all {{ tokenCount }} code tokens are identical, in the same order. Only whitespace and comments differ.
Output rejected
The result did not survive the token check, so it was discarded rather than shown to you. This is a bug in the tool, not in your code — please treat the input as unformatted.
Your LESS is tokenized and reformatted entirely in your browser. Nothing you paste or drop is ever uploaded to a server.
Formatting Less source, not compiling it
Variables, mixin calls, guards and operations are all left byte-identical; only whitespace and comments move. Compiling Less means resolving every one of those, which is a different and far larger job than laying the source out readably.
Escaped values are left alone
~"calc(100% - 10px)" is an escaped string, and its contents are treated as a
string literal rather than as code. That matters because escaped values usually exist precisely
to hold something the compiler should not touch — and by the same reasoning, a formatter should
not touch it either.
@{} interpolation
Read as a single unit, so the braces in .@{name}-box are never mistaken for the
start of a nested rule. Getting this wrong causes a formatter to indent everything after it
inside a phantom block, which is the most common way Less formatting goes visibly wrong.
A note on // comments
They are handled, but remember Less strips them at compile time anyway — they never reach your CSS. Minifying removes them here too; beautifying keeps them on their own line.
Working with SCSS instead?
Use the SCSS Minifier &
Beautifier, which handles $variables and #{} interpolation.
Frequently asked questions
Does this compile LESS to CSS?
No. It formats LESS source only — reindenting or collapsing it while leaving variables, mixin calls, guards and values byte-identical. Compiling Less requires resolving all of that, which is a different tool entirely.
Are @variables and @{} interpolation safe?
Yes. @variable declarations and references are ordinary tokens here, and @{name} interpolation is kept as one unit so its braces are never mistaken for a nesting level.
What about escaped values like ~"..."?
The quoted part is a string token, so its contents are never reformatted — which matters because escaped values often contain exactly the characters a formatter would otherwise want to tidy.
What happens to // comments?
Recognised and removed when minifying, preserved on their own line when beautifying. Note that Less treats // comments as source-only, so they would not have reached your compiled CSS anyway.
Is my source uploaded anywhere?
No. Everything runs in your browser.