EditorConfig Generator

EditorConfig generator - one set of indentation rules for the whole team

The EditorConfig generator assembles a ready configuration file from seven decisions: spaces or tabs, indent width, encoding, line ending, a final newline, trailing whitespace trimming and a Markdown exception. Copy the result into the root of your repository and every editor on the team formats code the same way, regardless of personal preferences.

What .editorconfig is and why it works

.editorconfig is a plain text file in INI format that describes formatting rules per file name pattern. It is not a command you run in a terminal and not a project dependency - it is configuration read by the editor itself. Because the file is versioned alongside the code, a new team member gets the right indentation right after the first git clone. The root = true entry at the top matters: without it the editor keeps searching parent directories and may pull in rules from a different project. The generator always writes that line.

Which rules the generator sets

How to build the file step by step

1. Pick the Spaces or Tabs tile. In tab mode the generator writes tab_width, because the width of a tab is a display concern rather than a count of characters.
2. Enter an indent width between 1 and 12. A value outside that range stops generation and shows a message instead of quietly substituting something else.
3. Set the encoding and the line ending. The defaults, utf-8 with lf, are the safe choice for projects that build on Linux.
4. Decide on the final newline and on trailing whitespace trimming. Both switches write an explicit true or false.
5. Click Generate .editorconfig, copy the output and save it as .editorconfig in the root of the repository.

At the start of a repository it is worth adding an ignore list from the gitignore generator next to it, and for Apache projects a configuration from the .htaccess file generator.

Narrower indents for frontend files

When you choose spaces and a width larger than two, the generator appends a section for js, jsx, ts, tsx, css, scss, json, yml, yaml and html files with a two space indent. That convention rules the JavaScript ecosystem and nested data files. At a width of one or two spaces the section is skipped, because it would repeat the global rule.

.php, .py, .go and .rs files are deliberately kept out of that list: PSR-12, PEP 8 and rustfmt call for four spaces, gofmt for tabs. They inherit the rule from the [*] section. One exception is always enforced: if you pick tabs globally, a separate spaces-only section is written for .yml and .yaml, because the YAML specification forbids tabs as indentation. A file indented with tabs will not parse at all, as a YAML validator confirms.

Line endings, Git and phantom changes in diffs

Windows terminates a line with a CR and LF pair, Unix-like systems with a single LF. Without a shared rule Git reports an entire file as modified even though nobody touched the code. Setting end_of_line = lf solves it on the editor side, paired with a .gitattributes file containing * text=auto eol=lf, which normalizes content inside the repository. If a diff still looks suspicious, inspect it with a code difference checker, and clean up indentation in HTML or CSS with the JS, CSS and HTML code beautifier.

Why Markdown needs an exception

In Markdown two spaces at the end of a line mean a forced line break. An editor with trim_trailing_whitespace enabled strips them on every save and quietly breaks your documentation. That is why the generator adds a section disabling the rule for .md and .markdown files:

[*.{md,markdown}]
trim_trailing_whitespace = false

The section appears only when you trim whitespace globally - otherwise it would be an entry with no effect.

Frequently asked questions