UtilityKit

500+ fast, free tools. Most run in your browser only; Image & PDF tools upload files to the backend when you run them.

Editorconfig Generator

Generate .editorconfig with global defaults and per-extension overrides.

About Editorconfig Generator

Few things derail a code review faster than a diff filled with 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 was created to solve this coordination problem by placing editor preferences directly in the repository. The EditorConfig Generator lets you configure indent style, indent size, end-of-line character, charset, trailing whitespace trimming, and final newline enforcement — then outputs a ready-to-commit .editorconfig file. You can define global defaults and add per-file-type overrides for Makefiles, Go files, or any format with non-standard requirements.

Why use Editorconfig Generator

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.

File-Type Granularity for Special Cases

Makefiles require hard tabs or they break. Go files use gofmt's tab-based indentation. The generator lets you define per-extension overrides so those special cases are handled correctly without overriding the project default.

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 Editorconfig Generator

  1. Choose your preferred indent style — spaces or tabs — and the indent size such as 2 or 4
  2. Select the end-of-line character: LF for Unix/macOS, CRLF for Windows, or CR for legacy systems
  3. Set the character encoding, typically UTF-8, and enable trim_trailing_whitespace if desired
  4. Toggle insert_final_newline to enforce POSIX-compliant files that end with a newline character
  5. Add any file-specific overrides for languages like Makefile that require tabs or Go that uses gofmt defaults
  6. Click Generate, review the output, copy it, and save it as .editorconfig in your repository root

When to use Editorconfig Generator

  • 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 onboarding a project that uses Makefiles or Go and needs tab-based indentation enforced
  • 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

Standard web project

Input: indent_style=space, indent_size=2, eol=lf, charset=utf-8, trim_trailing_whitespace=true, insert_final_newline=true

Output: root = true [*] indent_style = space indent_size = 2 end_of_line = lf charset = utf-8 trim_trailing_whitespace = true insert_final_newline = true [*.md] trim_trailing_whitespace = false [Makefile] indent_style = tab

Go project with 4-space Python

Input: indent_style=tab for Go, indent_style=space indent_size=4 for Python

Output: root = true [*] indent_style = tab indent_size = 4 end_of_line = lf charset = utf-8 insert_final_newline = true [*.py] indent_style = space indent_size = 4 [*.go] indent_style = tab indent_size = tab

Windows-first project (CRLF)

Input: indent_style=space, indent_size=4, eol=crlf, charset=utf-8

Output: root = true [*] indent_style = space indent_size = 4 end_of_line = crlf charset = utf-8 trim_trailing_whitespace = true insert_final_newline = true [*.sh] end_of_line = lf

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

Do I need a plugin for my editor to use .editorconfig?
Many editors like JetBrains IDEs, Visual Studio 2017+, and Neovim support EditorConfig natively without any plugin. VS Code requires the EditorConfig for VS Code extension, which is free and widely installed.
What is the difference between root = true and omitting it?
Setting root = true at the top of the file tells EditorConfig to stop looking for additional .editorconfig files in parent directories. Without it, settings from parent directories can bleed into your project unexpectedly.
Can I have different indentation for JavaScript and Python in the same project?
Yes. Use a [*] global section for defaults and then add [*.js] or [*.py] sections underneath with overrides. Rules in a more specific section take precedence over the global defaults.
Why does Makefile need tabs specifically?
The make utility parser requires recipe lines (the commands under a target) to be indented with a literal tab character. Spaces will cause a Makefile syntax error at runtime. The generator adds a [Makefile] override section that sets indent_style = tab.
Does EditorConfig enforce settings at commit time or only while editing?
EditorConfig only influences editor behavior while you are actively editing files. It does not run at commit time. For commit-time enforcement, pair it with a pre-commit hook using tools like editorconfig-checker or Prettier.
What does insert_final_newline do?
It ensures every file saved by the editor ends with a single newline character. This follows the POSIX text file convention and prevents the no newline at end of file warning that appears in git diffs and many code review tools.
Is charset = utf-8-bom ever appropriate?
Only for files that must be consumed by older Windows tools that require a byte order mark, such as certain legacy CSV processors. For modern projects, charset = utf-8 is always the correct choice and BOM should be avoided.
Can .editorconfig coexist with a Prettier config?
Yes, and they are designed to complement each other. EditorConfig handles editor-level mechanics (indentation on keypress, line endings on save), while Prettier enforces code style at format time. Set them consistently to avoid conflicts.

Explore the category

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.