EditorConfig Generator

It marks this file as the top of the project. EditorConfig normally walks up the folder tree merging every .editorconfig it finds, and root = true stops that search. Set it only in the file at your repository root, and leave it off in nested config files.

Use tabs where the language or format expects them, such as Makefiles (which require real tabs) or Go. You can keep spaces as the global default and add an override section for just those files with indent_style set to tab.

Each override is a section with a glob such as *.md or {*.yml,*.yaml}. The generator only writes the properties you actually set in that row, and every other setting is inherited from the [*] section above it, so an override can change one rule and nothing else.

In Markdown two spaces at the end of a line create a hard line break. If trim_trailing_whitespace stayed on, your editor would delete those spaces and quietly change how the document renders. The keep trailing ws checkbox emits trim_trailing_whitespace = false for that pattern.

The indent size field accepts whole numbers from 1 to 16. Common choices are 2 for web and config files and 4 for many backend languages. The value is written as indent_size, and EditorConfig also treats it as tab_width unless you set that separately.

JetBrains IDEs, Visual Studio and many others read .editorconfig with no plugin. VS Code, Vim, Sublime Text and Atom support it through a widely installed extension. Editors that do not understand a property simply ignore it, so the file is safe to commit anywhere.

It covers the properties teams reach for most: indent_style, indent_size, end_of_line, charset, trim_trailing_whitespace and insert_final_newline, plus tab_width on overrides. Rarely used properties like max_line_length are not exposed, but you can add them by hand after copying.

Yes. The file is assembled entirely in your browser from the options you pick, and nothing is uploaded to a server. You can use the tool offline once the page has loaded.