What does the root = true line do?

It tells EditorConfig-aware editors to stop searching parent directories for more .editorconfig files. You set it in the top-level file at your repository root so its rules are the final word for the project.

How do the [*] and file-specific sections interact?

The [*] block applies to every file, then more specific sections like [*.md] or [Makefile] override it for matching files. Later, more specific matches win, so you set sensible defaults and only override where a file type needs it.

Why must Makefiles use tabs?

GNU Make requires recipe lines to begin with a literal tab character; spaces cause a 'missing separator' error. The Makefile override forces indent_style = tab so the file stays valid even if your default is spaces.

Why keep trailing whitespace in Markdown?

In Markdown, two trailing spaces at the end of a line create a hard line break. Trimming them would silently change rendered output, so the Markdown override sets trim_trailing_whitespace = false.

Do editors apply this automatically?

Many editors (such as VS Code, JetBrains IDEs and Vim with a plugin) read .editorconfig natively or via an extension, applying the rules as you type and save. Check your editor's EditorConfig support if rules are ignored.

What is the .editorconfig Builder?

Build a valid .editorconfig file. Set indent style and size, line endings, charset, trailing-whitespace trimming, final newline and file-type overrides for Makefiles, YAML and Markdown. It runs free in your browser on Gera Tools, with nothing uploaded.

.editorconfig Builder

Name: .editorconfig Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

The .editorconfig builder generates a valid EditorConfig file so every contributor’s editor uses the same indentation, line endings and whitespace rules — regardless of personal settings. Choose your base style, add file-type overrides, then copy or download a ready-to-commit file.

Why `.editorconfig` belongs in every repository

Without a shared editor configuration, developers on different machines and editors silently disagree on tabs versus spaces, CRLF versus LF, and whether files end with a newline. These differences produce noisy diffs, break linters, and occasionally cause runtime errors (GNU Make breaks on space-indented recipes, Python cares about consistent indentation, YAML rejects tabs). A single .editorconfig file at the root of the repository resolves all of this at save time, before a commit even happens.

How it works

EditorConfig files are read top-down. The builder always emits root = true followed by a [*] section that applies to every file: indent_style, indent_size, end_of_line, charset, trim_trailing_whitespace and insert_final_newline. Editors then apply more specific sections on top — so a [*.md] or [Makefile] block overrides the [*] defaults only for matching files. Because later, more specific matches win, you set sane global defaults once and override only where a file type genuinely differs.

File-type overrides and why they matter

Three common overrides ship as toggles:

Section	Key setting	Reason
`[Makefile]`	`indent_style = tab`	GNU Make requires literal tabs in recipe lines; spaces cause a “missing separator” error
`[*.{yml,yaml}]`	`indent_size = 2`	YAML forbids tab indentation; 2 spaces is the universal YAML convention
`[*.md]`	`trim_trailing_whitespace = false`	Two trailing spaces in Markdown create a hard line break; stripping them silently changes rendered output

A minimal generated file

root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[Makefile]
indent_style = tab

[*.{yml,yaml}]
indent_size = 2

[*.md]
trim_trailing_whitespace = false

Editor support and workflow tips

Most modern editors support EditorConfig natively or via a small plugin:

VS Code: built-in, no extension needed
JetBrains IDEs (IntelliJ, WebStorm, etc.): built-in
Vim/Neovim: editorconfig-vim plugin
Emacs: editorconfig-emacs package

If your rules seem to be ignored, check that the extension is installed and that there is no higher-precedence setting overriding it in your user or workspace settings.

Pair .editorconfig (whitespace and encoding) with a formatter like Prettier or gofmt (full code style) for complete, automated consistency across the team. EditorConfig handles the structural rules; the formatter handles the stylistic ones.