What .editorconfig does
Three engineers on the same repo, three different editors: VS Code on Windows that adds CRLF, vim on Linux with tabs of 4 spaces, JetBrains on macOS with a personal tab width override. Three weeks later the diff is full of invisible whitespace changes, every PR has noise, blame becomes useless.
An `.editorconfig` file is the simple fix. It is a one-shot config at the root of the repo that every modern editor reads automatically (VS Code, JetBrains, vim, emacs, Sublime, Atom): which indent style, how many spaces, which line ending, which charset, whether to trim trailing whitespace, whether to add a final newline. No plugin to install for the popular editors, no config per developer.
This generator writes that file for you. Pick a preset for your stack (JavaScript / TypeScript, Python, Go, Polyglot, Windows-friendly, Strict Linux), tweak the defaults if you want, add per-pattern overrides for files that need different rules (`Makefile` always wants tabs, `*.md` should keep trailing whitespace because that is how line breaks are encoded), copy or download as `.editorconfig`, commit. Done in two minutes.
How to use it
- Pick a preset at the top: JavaScript / TypeScript, Python, Go, Polyglot, Windows-friendly, Strict Linux. Each preset fills sensible defaults you can change.
- Leave root = true on. It tells editors "stop looking up the directory tree". Without it, an `.editorconfig` higher up in the hierarchy (e.g. in your home directory) can override yours.
- Edit the **default section [*]: which charset, end_of_line, insert_final_newline, trim_trailing_whitespace, indent_style, indent_size, max_line_length**.
- Add per-pattern overrides for files that need different rules. `Makefile` must use real tabs (Make refuses tabs converted to spaces). **`*.md` should keep trailing whitespace (markdown encodes line breaks as two trailing spaces). `*.go`** typically uses tabs of width 4.
- For Windows-only repos with shell scripts, you can mix endings: **`*.{ps1,bat,cmd}` = crlf, `*.sh` = lf**. Mismatched endings on `.sh` files break execution on Linux.
- Empty a field by clicking "keep" in the segmented bar. The key will be omitted from the output for that section, so the value from a parent section (or the editor default) wins.
- Click Copy or Download to save as `.editorconfig`, then commit to the root of your repo. Every IDE picks it up on next open, no installation needed for the popular ones.
When this is useful
Six concrete situations where adding an .editorconfig saves your team real time:
- First commit in a new repo. Pick the right preset for your stack, drop `.editorconfig` in the root, commit. Every editor opening this repo from now on uses the same indentation and line endings without anyone having to configure anything.
- Mixed-OS team (Windows + macOS + Linux). The single most common source of "spurious diff" PRs is line endings. Setting `end_of_line = lf` once kills the entire category, regardless of git's autocrlf wizardry.
- Onboarding a new developer. They clone the repo, open in their editor of choice, and indentation just works. No "wait, why does my IDE indent with 4 spaces here?" surprises.
- Open-source project that accepts external PRs. External contributors use random editors. Without `.editorconfig`, half the PRs need a "fix whitespace" follow-up. With it, the PR diff is just the actual change.
- Repo with multiple languages. Python wants 4 spaces, JS wants 2, Go wants tabs of 4, YAML wants 2 spaces, Makefiles want literal tabs. One `.editorconfig` with a few per-pattern blocks covers all of them in twenty lines.
- Pre-commit hook for whitespace. Combined with a pre-commit hook (`pre-commit` framework has an `editorconfig-checker` integration), the rules become enforceable instead of just suggested.