Indent Fixer

What is code indentation normalizing?

Indentation is the leading whitespace — tabs or spaces — that shows a code block's nesting level. Files edited by different people or tools often end up mixing tab-indented and space-indented lines, or inconsistent widths, which makes diffs noisy and code harder to read. This tool detects the indentation style your code actually uses and rewrites every line to one consistent width and character, without touching the code itself.

How to use Indent Fixer

1. Paste your code into the Input code panel, or click Example to try a sample.
2. Check the detected indentation style shown above the target selector.
3. Pick a target width — 2, 4 or 8 spaces, or Tabs — under "Normalize to".
4. Review the normalized code in the Result panel.
5. Click Copy or Download to grab it.

How indentation detection works

Absolute indentation width alone doesn't reveal the step size a file uses — a line indented 8 spaces could be one level of 8-space indent or two levels of 4-space indent. The reliable signal, the same one code editors like VS Code use, is the difference in leading-whitespace length between one line of real code and the previous one. The most common positive difference is the detected step; whichever of tabs or spaces shows up more often is the detected character:

// Before (4-space indentation)
function greet(name) {
    if (name) {
        console.log("Hi, " + name);
    } else {
        console.log("Hi!");
    }
}

// After (normalized to 2 spaces)
function greet(name) {
  if (name) {
    console.log("Hi, " + name);
  } else {
    console.log("Hi!");
  }
}

Only each line's leading whitespace is rewritten — everything from the first non-whitespace character onward is left byte-for-byte untouched. A lightweight shared state machine also tracks single/double-quoted strings, backtick template literals, triple-quoted Python strings and /* */ block comments as it scans, and skips reindenting any line that is a continuation of one of those constructs, since that whitespace is string/comment content, not code structure. If a file genuinely mixes two different indentation widths in different blocks, the more common width wins and the minority is treated as noise — this is a documented trade-off of using one global step size rather than a per-block heuristic. Note too that this rewrites each line's proportional indent level, not its "correct" nesting depth: a line that's accidentally over- or under-indented in the original file keeps that same relative level in the output, just measured in the new unit — the tool has no per-language awareness of blocks/braces to detect that kind of mistake.

Frequently asked questions

How does the automatic indentation detection work?

It uses the same heuristic most code editors use: instead of looking at each line's absolute indentation width, it looks at the difference in leading-whitespace length between consecutive lines of real code. The most common positive difference is the detected step size (usually 2, 4 or 8), and whichever of tabs or spaces appears more often is the detected character.

Will it corrupt strings, template literals or comments?

No. It tracks a small state machine as it scans the code (single/double-quoted strings, backtick template literals, triple-quoted Python strings, and /* */ block comments) and only ever rewrites a line's leading whitespace when that line is not a continuation of one of those constructs. The rest of every line is copied through untouched.

Does it work for languages other than JavaScript?

Yes, reasonably well for JS/TS, Python, CSS, JSON and similar C-like or Python-like languages, because it uses one lightweight shared tokenizer instead of a full parser per language. Very unusual syntax (custom raw-string delimiters, uncommon comment styles) may not be handled perfectly.

Is it safe to paste proprietary code here?

Yes. All processing happens in your browser; no code is ever sent to a server.