CSS, LESS & SCSS Formatter

What is a CSS, LESS and SCSS formatter?

A stylesheet formatter reads your CSS and prints it back with one consistent shape: one declaration per line, every block indented the same way, every colon and comma spaced the same way. The rules that come out are the rules that went in. Only the layout changes. This page runs Prettier, the same formatter your editor uses on save, so what you get here matches what a project with Prettier configured would produce.

Pick CSS, LESS or SCSS with the buttons above the panels. That choice selects which of Prettier's three stylesheet parsers reads your input, which matters once your file contains anything the plain CSS grammar does not describe. Set the indent to 2, 4 or 8 spaces and choose single or double quotes. The right panel updates as you type. Both panels count characters, Copy Output hands the finished stylesheet to your clipboard, and unparseable input gets the reason plus the line and column where the parser gave up.

Nothing you paste leaves the page. The formatter downloads once from a CDN when you open the tool and then runs inside your browser tab, so a stylesheet from a client project or an unreleased product never reaches a server.

When to use it

The clearest case is a stylesheet you have to read but nobody meant you to read. A vendor theme, a plugin, a build output someone deployed without the source map. What is on the server is one line, forty kilobytes wide, and you need the rule setting the header height. Formatting does not give you back the original file, because the minifier already destroyed the comments and the variable names. It gives you something with line numbers, which is enough to search and scroll.

The second case is a file that three people edited with three different editor configurations. One of them indents with tabs, one with two spaces, one with four, and somebody's editor trims trailing whitespace while somebody else's does not. The file works. Reviewing it does not, because every diff is half real changes and half reindentation. Running the whole file through one setting collapses that noise, and the next diff shows only the change.

Smaller reasons come up constantly. Checking what a build step emitted before you trust it. Reading a snippet from a bug report before answering it. Seeing how much churn a formatter would cause in a repository that has none, before you propose adding one. In each of those you want to look at a stylesheet rather than ship it, and looking is easier when the shape is predictable.

How this tool works

Prettier does not adjust the whitespace it finds. It parses your stylesheet into a syntax tree, discards the original text, and prints a new document from that tree. This is the most useful thing to understand about it. Because the printer only ever sees the tree and your options, formatting the same rules twice produces identical bytes, and reformatting an already-formatted file changes nothing. It also means hand alignment does not survive. If you lined up a column of values with extra spaces, the parser never recorded that you did, so the printer cannot reproduce it. Beyond the few options exposed here, its layout opinions are not negotiable. That is the trade: you give up local control and stop arguing about it.

Its opinions are worth knowing before you run a whole file through them. Declarations go one per line, indented by the width you picked. A run of blank lines collapses to one, on the reasoning that a single blank line is a deliberate separator and four are an accident. Property names are lowercased while values are left as written, so MARGIN becomes margin and a value of AUTO stays AUTO. Hex colours are lowercased without being shortened: #FFFFFF comes out as #ffffff and stays six digits. A decimal missing its leading zero gains one, turning .2 into 0.2. Long comma-separated values, the kind a transition or a font shorthand produces, break onto one line per item rather than running off the side.

What it will not do matters as much. It does not reorder declarations and it does not merge or deduplicate anything. If a rule sets color twice, both lines survive in their original order, because the later one wins and reordering them would change which colour the browser paints. Two blocks sharing a selector stay as two blocks for the same reason. Comments are preserved, including the double-slash comments that only SCSS and LESS allow. A formatter that rewrote your cascade without telling you would be a refactoring tool wearing a formatter's clothes.

The three parsers differ in what they recognise. The SCSS parser understands dollar variables, ampersand nesting and the &__element pattern, @use and @forward, @mixin and @include, @if and @else, @each, and #{} interpolation in a selector; a Sass map gets expanded with one key per line. The LESS parser handles at-sign variables, mixin definitions and calls with their parentheses, guards written with when, :extend, and escaped values in the ~"..." form. The plain CSS parser is more forgiving than you might expect and accepts some of this without complaint, but it reads those constructs as unfamiliar text rather than as the thing they are. Choosing the button that matches your file is how spacing inside a mixin call or a Sass expression gets handled instead of passed through.

When a file cannot be parsed, the right panel gives the reason and the exact position, for example "Unclosed block (line 1, column 7)". That position is where the parser could no longer make sense of the input, which is often below the real mistake. An unclosed brace on line 12 tends to be reported at the end of the file, because that is where running out of input became a problem. Read it as a starting point and work upward.

Examples

• A minified stylesheet with no source map

  Input

  .btn{padding:8px 16px;border:0;border-radius:4px;background:#5fc2ef;color:#0b1116}.btn:hover{background:#4aa8d4}@media(max-width:600px){.btn{width:100%}}

  Output

  .btn {
    padding: 8px 16px;
    border: 0;
    border-radius: 4px;
    background: #5fc2ef;
    color: #0b1116;
  }
  .btn:hover {
    background: #4aa8d4;
  }
  @media (max-width: 600px) {
    .btn {
      width: 100%;
    }
  }
  

  The media query gains a space after @media and its contents get a second level of indent, so the nesting is visible at a glance.

• SCSS nesting, a variable and a mixin include

  Input

  $gap:16px;.card{padding:$gap;&__title{font-weight:700}&:hover{box-shadow:0 2px 8px rgba(0,0,0,.2)}@include respond(md){padding:$gap*2}}

  Output

  $gap: 16px;
  .card {
    padding: $gap;
    &__title {
      font-weight: 700;
    }
    &:hover {
      box-shadow: 0 2px 8px rgba(0, 0, 0, 0.2);
    }
    @include respond(md) {
      padding: $gap * 2;
    }
  }
  

  Set with the SCSS button. The alpha value .2 gains its leading zero, and the multiplication in $gap*2 gets spaces around the operator.

• LESS variables and a mixin call

  Input

  @brand:#5fc2ef;.mixin(@w){width:@w}.panel{.mixin(100%);color:darken(@brand,10%);.inner{margin:0}}

  Output

  @brand: #5fc2ef;
  .mixin(@w) {
    width: @w;
  }
  .panel {
    .mixin(100%);
    color: darken(@brand, 10%);
    .inner {
      margin: 0;
    }
  }
  

  Set with the LESS button. The mixin definition is printed as a block while the call inside .panel stays a single statement, because the parser can tell them apart.

• Four-space indent with single quotes

  Input

  a{content:"x";font-family:"Fira Code",monospace}

  Output

  a {
      content: 'x';
      font-family: 'Fira Code', monospace;
  }
  

  Quote style is a printing choice, so the characters inside the string are untouched while the delimiters around it change.

• A file three people edited differently

  Input

  .a   {
   color:RED;
     MARGIN : 0   AUTO ;
  }
  
  
  .b{color:#FFFFFF}

  Output

  .a {
    color: RED;
    margin: 0 AUTO;
  }
  
  .b {
    color: #ffffff;
  }
  

  The property name MARGIN is lowercased while the values RED and AUTO are left alone, the run of blank lines becomes one, and #FFFFFF is lowercased without being shortened.

Frequently asked questions

• Can formatting change how my page looks?

  No. The whitespace between selectors, braces, colons and declarations carries no meaning in CSS, so moving it around cannot change what a browser paints. The one place whitespace does matter is inside a quoted string, and Prettier leaves the characters inside a string exactly as it found them. It may swap the quote marks around a string if you choose the other quote style, but it will not touch what is between them.

• Will it reorder my declarations or merge duplicate rules?

  Neither. Order is meaning in CSS. When the same property is set twice in one block the later declaration wins, and when two blocks share a selector the later block wins, so a formatter that tidied either of those would silently change which styles apply. Everything stays in the order you wrote it. If you want duplicate rules found and removed, that is a linting job rather than a formatting one, and it wants a human deciding each case.

• Should I format my CSS or minify it?

  Both, at different moments. Format the version you and your team read and edit, and minify the version the browser downloads. They are outputs of the same source aimed at different readers. Once you are done reading a stylesheet here, the CSS Minifier on this site does the other direction, stripping the whitespace back out and reporting how many bytes it saved.

• I write LESS. Should I format it here or compile it?

  Depends what you want at the end. If LESS stays your source language and you want the file readable, format it with the LESS button and keep going. If you are getting off LESS, or you need plain CSS for something that cannot compile, the Less to CSS compiler on this site resolves the variables, mixins and nesting into standard CSS. Compile first and format the result, since compiler output arrives with its own spacing habits.

• Why does the tool take a moment before it works?

  Because a real parser has to arrive first. Prettier and its stylesheet plugin come to about 74 KB compressed, more than belongs in every page of this site, so they are fetched only when you open this tool. The toolbar tells you when they have landed. Anything you type before then is held and formatted the moment the formatter is ready, so there is no need to wait or retype.

• Are there stylesheets it cannot handle?

  Template syntax is the common one. A PHP tag or a Handlebars expression embedded in a stylesheet stops the parser, because neither is valid in any of the three dialects. You get a position rather than a shrug, so you can see which construct it choked on, strip it out, format the rest and put it back. Recent CSS is less of a problem than people expect: container queries, :has() and native nesting all parse.

• Our stylesheets are a mess across a dozen repositories. Where do we start?

  Not with a browser tab. Formatting one file by hand is fine. Formatting a codebase is a decision about tooling and about the day you make the switch, because reformatting everything at once produces a commit that touches every line and makes git blame useless unless you configure it to skip that revision. Zinc Online Solutions has run that migration before: agree the config, apply it in one isolated commit, record that commit so history stays readable, then enforce it in CI. Tell us how many repositories are involved and whether anyone is still authoring LESS, and we will tell you what the switch costs and what order to do it in.