Free · Fast · Privacy-first

CSS Indentation Fixer

Fix inconsistent, mixed, or missing indentation in any CSS file with FixTools.

⚡

Normalises all indentation to consistent spaces

🔒

Fixes mixed tab and space indentation

✨

Applies correct indent depth for nested at-rules

⚡

Free, instant, and browser-based

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this CSS Formatter to your website

Drop the CSS Formatter into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/css-tool/css-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="CSS Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/css-tool/css-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="CSS Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Why Inconsistent CSS Indentation Causes Problems and How to Fix It Fast

Inconsistent indentation is one of the most common quality problems in CSS written by multiple contributors over time. One developer uses tabs because that is what their editor defaults to, another uses two spaces because that is what their team standard says, a third uses four spaces because they copied a snippet from a tutorial that did, and the result is a stylesheet that is visually chaotic and practically unmaintainable. The problem is compounded by editors that auto-detect indentation and silently switch style halfway through a file, by copy-pastes from external sources that bring their own indentation conventions with them, and by automated tooling that occasionally re-saves files with whatever default settings happen to be active at the time. A dedicated indentation fixer cuts through all of this by applying a single standard to the entire file in one operation, eliminating every legacy inconsistency at once instead of trying to fix them rule by rule.

Indentation consistency matters far beyond visual tidiness. Inconsistent indentation in CSS, particularly around nested at-rule blocks like media queries and container queries, can make it genuinely difficult to determine the scope of a given rule. Is this declaration inside the media block or outside it? Is this keyframe step part of the animation above or the one below? With consistent indentation, the answer is visually obvious in a fraction of a second. With inconsistent indentation, you must count braces, mentally track nesting levels, and double-check yourself before making any change. That extra cognitive load multiplies across every editing session and every code review, and it introduces real errors when a developer assumes the wrong scope and pushes a change that ends up applying to the wrong selector.

Fixing indentation also has a direct impact on version control hygiene. A file with inconsistent indentation will generate large, noisy diffs whenever someone changes even a single property, because their editor will helpfully reformat the surrounding lines on save to whatever the local indentation setting happens to be. Reviewers then have to wade through dozens of whitespace-only line changes to find the one real semantic change, which slows reviews and increases the chance that a real bug slips through. Running the indentation fixer on the entire file before starting work produces a clean baseline so that subsequent diffs only show intentional changes. This is especially valuable in long-lived projects where the CSS file has accumulated years of mixed indentation from many contributors and every commit currently looks visually noisy regardless of how small the underlying change actually is.

There is also a downstream impact on automated tooling. Linters, formatters, build steps, and migration scripts all behave more predictably when the input is consistently indented. Tools that try to parse CSS structurally can usually handle any whitespace, but tools that operate on text patterns, including many quick refactoring scripts and ad-hoc one-liners, work much more reliably when indentation is uniform. Fixing indentation across the codebase removes a quiet source of intermittent tooling failures and gives every script in your build pipeline a more predictable input to work with. The improvement compounds because each downstream consumer of the CSS becomes more reliable simultaneously rather than each having to defensively handle every possible whitespace variation on its own.

MDN Web Docs: CSS Google Web.dev: Learn CSS

How to use this tool

💡

Paste CSS with inconsistent indentation and click Format. The output uses consistent two-space indentation throughout.

How It Works

Step-by-step guide to css indentation fixer:

1
Paste your CSS
Open the CSS Formatter and paste the stylesheet with inconsistent indentation. The input can be a partial snippet, a full file, or a multi-file concatenation, the formatter handles any size and any mixture of indentation styles in a single operation without needing you to clean anything up first.
2
Click Format
Click the Format button to apply consistent two-space indentation throughout the entire pasted content. The fixer processes the input in milliseconds, normalising tabs, four-space blocks, and any other variations to a single uniform pattern that matches the most widely adopted CSS convention.
3
Review the output
Scan through the formatted output to confirm that all rule blocks and nested at-rules are indented at the levels you expect. Look specifically at media queries, keyframes, and any deeply nested at-rules, these are the places where indentation problems most commonly hide and where verification is most valuable.
4
Replace your source file
Copy the fixed output and use it to replace your source CSS file. Commit this change on its own, with a clear message indicating that it is a pure indentation normalisation, before resuming any other work. This keeps the formatting commit isolated and reversible.

Real-world examples

Common situations where this approach makes a real difference:

A developer takes over a five-year-old project with CSS files that mix two-space, four-space, and tab indentation from a long history of different contributors, and runs the fixer on every file before starting their first feature. The clean baseline lets them read the files quickly, spot duplicate selectors, and understand the existing structure without the cognitive overhead of decoding whitespace differences along the way.

A team introduces a code review requirement that all CSS must use consistent indentation and uses the online fixer to clean up every existing file in a single dedicated pull request before enforcing the policy. The standalone formatting PR is reviewed quickly because reviewers can verify that no semantic change occurred, and from that point onward all new diffs in the project are free of indentation noise.

A developer notices their editor's CSS formatter is producing unexpected indentation and uses the online tool to confirm what correctly indented output should look like before debugging the local editor configuration. Having a known-good reference output eliminates speculation about whether the editor or the source CSS is at fault and shortens the debugging cycle.

A documentation site author is preparing CSS examples for a tutorial and runs every snippet through the indentation fixer before publishing, ensuring readers see consistently indented examples regardless of how the snippets were originally authored. This produces a more polished educational experience and avoids confusing learners who would otherwise wonder why different examples in the same tutorial follow different conventions.

When to use this guide

Use this when CSS has mixed tab and space indentation, inconsistent indent levels, or properties that are not indented at all, common in hand-edited or multi-author stylesheets.

Pro tips

Get better results with these expert suggestions:

Run the fixer on the entire file, not just changed sections

Fixing only the indentation of the section you are currently editing leaves the rest of the file inconsistent and guarantees the problem recurs the next time someone touches a different part. Format the entire file in one pass for a fully consistent baseline, then commit that pass on its own before continuing with any other work.

Commit indentation fixes as a standalone commit

When fixing indentation across a large file, make it a separate commit with a clear message like "Normalise CSS indentation". This keeps the indentation change distinct from logic changes, makes the commit easy to revert if anything unexpected happens, and preserves the usefulness of git blame for actual semantic history rather than burying it under whitespace churn.

Check @media rule indentation specifically

Nested at-rules require two levels of indentation: the @media or @supports rule itself sits at the top level, and the rules inside it are indented one additional level. Verify this nesting is correct after fixing, especially when the file mixes legacy media query syntax with modern container queries that may have been added later by different contributors.

Use the fixer as a diagnostic tool

If the indentation fixer produces unexpected output, the source CSS may have structural errors such as a missing brace or an unterminated string. The formatter's output reflects the actual brace structure of the file, so irregular output often points directly at the line where the structural problem lives. Treat surprising output as a diagnostic signal, not a bug in the tool.

Fix indentation before adding new contributors

Run the indentation fixer on all CSS files before new team members join a project. Starting from a consistent baseline prevents them from unknowingly introducing mixed indentation.

Fix indentation before refactoring

Consistent indentation reveals the true structure of a stylesheet before you start moving rules around. Refactoring consistently indented CSS is significantly easier and produces cleaner diffs.

Fix tabs vs. spaces issues in one step

If your CSS mixes tab-indented and space-indented sections, a common problem in files edited across different operating systems, the fixer normalises everything to spaces in one paste.

FAQ

Frequently asked questions

The formatter applies two-space indentation, which is the most widely adopted convention in the CSS community and the default for tools such as Prettier and the Google CSS style guide. Each nested level adds two more spaces, so a rule inside a media query sits at four spaces and a deeper nested at-rule would sit at six. This convention scales cleanly to any nesting depth and produces consistent visual structure across files of any size, which is why it has become the de facto standard.

Yes. Whether the input uses tabs, spaces, or a mix of both in the same file, the fixer normalises the entire content to consistent space-based indentation. This is particularly useful for files that have been edited across different operating systems or by developers with different editor defaults, where tab characters and space characters often end up interleaved within the same rule block in ways that are nearly impossible to fix by hand without missing some instance.

No. Indentation is whitespace and has no effect on how the browser parses or applies CSS. All style rules, selectors, property names, values, and at-rules are preserved exactly, and the rendered page will look identical before and after the fix. This makes indentation normalisation one of the safest possible changes to a CSS file, you can run it on production CSS without any risk of visual regression, which is why it makes such a good standalone commit to land first before any riskier refactoring.

The default output uses two-space indentation. For four-space indentation, consider running Prettier locally with the tabWidth option set to 4, which lets you configure the indentation width on a per-project basis. The browser formatter is intentionally opinionated about indentation to keep the tool fast and configuration-free; for projects that have committed to a non-default indentation width, a configured local tool is the right fit.

The most common causes are multiple contributors with different editor settings, copy-pastes from external sources that bring foreign conventions with them, editor auto-detection silently switching between tabs and spaces partway through a file, long-lived files that predate any team formatting standard, and code generators or templating systems that emit CSS with their own internal conventions. Each cause individually is mild; together over years they produce the chaotic mixed indentation that legacy projects are famous for.

Fix indentation on the entire existing file first, commit that change separately with a clear message, and only then start writing new CSS. This ensures your new code is being written into a consistent environment, makes the indentation fix easy to revert if needed, and keeps the diff of your subsequent feature work clean and reviewable. Doing it in the other order means your feature commit will be polluted with whitespace changes from sections you did not actually modify.

The formatter processes plain CSS only. CSS-in-JS template literals contain JavaScript syntax around the CSS, which the formatter is not designed to parse. The practical workaround is to extract the CSS portion from inside the template literal, run it through the formatter, and paste the fixed CSS back inside the literal. For projects that use a lot of CSS-in-JS, consider running a JavaScript-aware formatter like Prettier instead, which understands the JavaScript wrapper as well as the CSS inside it.

The formatter is designed for standard CSS. Basic SCSS and Less constructs that closely resemble plain CSS, such as variable declarations using @ or $ and standard nested rules, may format correctly, but preprocessor-specific syntax such as Sass functions, mixins, and selector nesting with the ampersand symbol may not produce the expected output. For SCSS and Less specifically, use a preprocessor-aware formatter such as Prettier with the appropriate plugin enabled.

No. The fixer is purely a whitespace operation. Declarations stay in the order you wrote them, rules stay in the order they appear in the file, and at-rule blocks remain in their original positions. If you want to reorder properties alphabetically or group rules logically, that is a separate operation handled by tools like stylelint with the appropriate ordering plugin. The fixer focuses only on indentation so that the resulting commit is unambiguously a whitespace change with no semantic side effects. Mixed-indentation files cause real problems beyond visual inconsistency: some build tools fail on tab-space combinations, code review diffs show false changes when indentation flips, and editors auto-indent incorrectly when nesting depth cannot be detected. Running every CSS file through an indentation fixer before committing eliminates an entire class of merge conflicts and lets your team focus on actual content changes during code review. Some editors silently mix tab and space characters when developers paste code from different sources. Indentation fixers normalize the underlying character stream regardless of what your editor displays, so subsequent edits stay consistent. This matters especially when your build pipeline includes minification, because mixed indentation can occasionally produce subtle output differences. Establishing one indentation style across your stylesheet collection also makes code review faster, since reviewers can spot real structural changes immediately instead of being distracted by formatting inconsistencies in the diff.