Editorconfig Generator

About this tool

Few things derail a code review faster than a diff full of whitespace-only changes caused by teammates using different editor defaults. One developer uses tabs, another spaces; one saves with CRLF line endings on Windows while another uses LF on macOS. The .editorconfig format solves this by placing editor preferences in the repository. The EditorConfig Generator lets you set root, charset (utf-8, latin1 or utf-16le), end_of_line, indent_style, indent_size, insert_final_newline and trim_trailing_whitespace for the [*] section, then add per-extension override blocks such as [*.py] or [*.{js,ts}] with one line per override. The output updates as you edit and shows line and byte counts; copy it and save it as .editorconfig in your repository root.

Why use it

• Eliminates Whitespace-Only Diff Noise: Enforcing a shared indent style and line ending at the repository level stops editors from silently reformatting files on save, keeping diffs clean and code review focused on logic rather than invisible character differences.

• Works Across Every Major Editor and IDE: EditorConfig is natively supported by JetBrains IDEs, Visual Studio, Atom, and many others, with an official VS Code extension. One file covers your entire team regardless of their editor choice.

• Prevents CRLF vs LF Merge Conflicts: Mixed line endings are one of the most frustrating sources of cross-platform merge conflicts. Specifying end_of_line in .editorconfig ensures all saves write the correct line ending before files ever reach version control.

• Per-Extension Granularity for Special Cases: Override lines let Python use four spaces, Markdown keep trailing spaces, or Go files use tabs without changing the project default. Files without an extension, such as Makefile, need a [Makefile] section added by hand.

• Zero Runtime Overhead, Fully Static: The .editorconfig file is read only by editors, not by build tools or CI pipelines. There is no runtime cost, no package to install globally, and no CI configuration needed — it just works wherever the editor opens the file.

• Complements Linters Without Duplicating Config: EditorConfig handles low-level editor mechanics (indentation, line endings, encoding) while tools like ESLint or Prettier handle language-level style rules. Together they cover the full spectrum of formatting consistency.

How to use

1. Set root, charset and end_of_line in the first row — root = true stops editors from reading .editorconfig files in parent directories.
2. Choose indent_style (space or tab), type an indent_size such as 2, 4 or tab, and set insert_final_newline.
3. Set trim_trailing_whitespace for the default [*] section.
4. Add per-extension overrides, one per line, as ext[,ext]|indent_style|indent_size|trim_trailing_whitespace|end_of_line — for example py|space|4|true|lf or md|||false|. Leave a field empty to skip it.
5. Check the Generated .editorconfig box, which updates as you edit, then click Copy and save it as .editorconfig in your repository root. Reset restores the defaults.

When it helps

• When starting a new project to establish formatting consistency from the first commit
• When your team spans multiple operating systems and line-ending conflicts keep appearing
• When a new contributor's editor keeps reformatting files with wrong indentation on every save
• When a project mixes languages with different indentation conventions, such as two-space JavaScript and four-space Python
• When you want a lightweight formatting baseline before deciding whether to adopt Prettier or another formatter
• When contributing to an open source project that requires an .editorconfig as part of its contributing guidelines

Examples

root=true, charset=utf-8, end_of_line=lf, indent_style=space, indent_size=2, insert_final_newline=true, trim_trailing_whitespace=true; overrides: js,ts|space|2|true|lf, md|||false|, py|space|4|true|lf

root = true

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

[*.{js,ts}]
indent_style = space
indent_size = 2
end_of_line = lf
trim_trailing_whitespace = true

[*.md]
trim_trailing_whitespace = false

[*.py]
indent_style = space
indent_size = 4
end_of_line = lf
trim_trailing_whitespace = true

indent_size=4, end_of_line=crlf, other settings default; override: sh||||lf

root = true

[*]
charset = utf-8
indent_style = space
indent_size = 4
end_of_line = crlf
insert_final_newline = true
trim_trailing_whitespace = true

[*.sh]
end_of_line = lf

indent_style=tab, indent_size=tab, other settings default; override: py|space|4||

root = true

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

[*.py]
indent_style = space
indent_size = 4

Tips

• Always include root = true as the first line in your .editorconfig to prevent settings inheritance from parent directories on developer machines
• Add a [*.md] section with trim_trailing_whitespace = false if you write Markdown, because trailing spaces in Markdown create intentional line breaks and should not be trimmed
• Pair your .editorconfig with a CI step using editorconfig-checker to reject files that violate the rules at pull request time, not just at editor save time
• If your project uses both tabs and spaces for different file types, document the reasoning in a comment line starting with # above each section
• Set indent_size = tab in Go file sections to defer indentation width to the editor's tab display setting, which is the convention followed by gofmt

Frequently Asked Questions

Glossary

indent_style

An EditorConfig property set to either tab or space that tells the editor which character to insert when the Tab key is pressed or indentation is auto-applied.

end_of_line

Specifies the line ending character written when a file is saved: lf (Unix/macOS), crlf (Windows), or cr (legacy Mac). Consistent line endings prevent cross-platform merge conflicts.

trim_trailing_whitespace

When set to true, the editor removes any whitespace characters at the end of lines before saving, keeping files clean and preventing invisible diff noise.

insert_final_newline

Ensures the editor appends a newline character at the very end of the file on save. Required by the POSIX text file standard and prevents the no newline at end of file git diff warning.

charset

Specifies the file encoding the editor should use when saving. utf-8 is the universal default for modern projects. utf-8-bom adds a byte order mark required by some legacy Windows tools.

Glob section header

A pattern like [*.js] or [Makefile] at the start of an EditorConfig section that limits the rules below it to files matching that pattern. Supports wildcards and brace expansion.