EditorConfig Generator

Five developers, three editors, two operating systems. The PR diff is full of tabs-vs-spaces noise and \r\n line endings mixed with \n. You add a style guide to the wiki — nobody reads it. You configure VS Code workspace settings — the two JetBrains devs don’t get them. You need one file that every editor reads automatically, no plugins for most IDEs, and it takes 30 seconds to set up. That file is .editorconfig.

Why This Generator (Not Your IDE Settings)

Your IDE’s formatter settings only apply to people using the same IDE with the same config. .editorconfig is a cross-editor standard supported natively by VS Code, JetBrains, Vim, Emacs, and Sublime Text. This tool generates the file visually — pick a preset (Web, Python, Go, Java), toggle indent style/size per file type, set line endings and charset, and copy the result. Everything runs in your browser; no data is sent anywhere.

What Is EditorConfig?

EditorConfig is a file format and collection of text editor plugins that help maintain consistent coding styles across different editors and IDEs. A .editorconfig file defines rules like indentation, line endings, and charset that editors automatically apply when you open a file — no team-wide IDE configuration required.

EditorConfig is natively supported in many editors including Visual Studio Code, JetBrains IDEs, Vim, Emacs, Sublime Text, and Atom. For other editors a plugin is available.

How to Use This Tool

1. Choose a Preset (Optional)

Click one of the preset buttons to populate the form with a sensible starting configuration:

• JavaScript / TypeScript — 2-space indent, LF line endings, UTF-8, no trailing whitespace. Markdown sections keep trailing whitespace (for line breaks).
• Python — 4-space indent following PEP 8, 79-character line limit for .py files, LF, UTF-8.
• Go — Tab indent matching gofmt output, LF, UTF-8.
• Mixed Project — A catch-all * section plus per-language overrides for Python, Go, Makefile, and Markdown.

2. Configure Root

Enable root = true if this .editorconfig sits at the root of your repository. This stops editors from looking for additional .editorconfig files in parent directories.

3. Add and Configure Sections

Each section targets a set of files using a glob pattern (e.g. *, *.py, *.{js,ts}, Makefile). Use the Pick… dropdown to insert common patterns quickly.

For each section you can set:

Set any property to unset (inherit) to omit it from that section — the property will be inherited from a wider-matching section above (e.g. [*]).

4. Reorder or Remove Sections

Use the ↑ / ↓ arrows to reorder sections and the Remove button to delete one. Section order matters: more-specific patterns should come after the general [*] catch-all.

5. Copy the Output

Click the Copy button to copy the generated .editorconfig to your clipboard, then create a .editorconfig file at the root of your project and paste the content.

All processing runs entirely in your browser. No configuration data is sent to any server.

Understanding the .editorconfig Format

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

The file is read top-to-bottom. When multiple sections match a file path, the last matching rule wins for each property. The general [*] section provides defaults; more specific patterns override only the properties they list.

Glob Pattern Reference

EditorConfig uses its own glob syntax (not the same as shell globs):

Common real-world patterns:

[*]                    # All files
[*.{js,ts,jsx,tsx}]   # JavaScript and TypeScript
[*.{py,pyx}]          # Python source and Cython
[Makefile]            # Exactly "Makefile" (case-sensitive on Linux)
[*.md]                # Markdown
[*.{yaml,yml}]        # YAML

Common Configurations by Language

JavaScript / TypeScript (2-space)

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

Python (PEP 8 compliant)

root = true

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

[*.py]
max_line_length = 79

Go (gofmt compatible)

root = true

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

Frequently Asked Questions

Does EditorConfig override my editor settings?

Yes, but only for files within the project directory (and subdirectories). Settings in .editorconfig take precedence over your personal editor preferences for files within that project, which is the intended behaviour for team consistency.

Should I commit .editorconfig to version control?

Yes. The .editorconfig file should be committed to your repository so all contributors automatically benefit from the same settings.

What is the difference between indent_size and tab_width?

indent_size sets the number of columns used for each level of indentation when indent_style = space. tab_width sets the visual width of a tab character (defaults to indent_size if not specified). For most projects you only need indent_size.

Why does Markdown have trim_trailing_whitespace = false?

In Markdown, two trailing spaces at the end of a line produce a hard line break (<br>). Trimming whitespace automatically would break this syntax. Set trim_trailing_whitespace = false in the [*.md] section to preserve intentional trailing spaces.

Does EditorConfig affect linters and formatters?

Some tools (ESLint, Prettier, Black) read EditorConfig settings automatically. For example, Prettier uses indent_style, indent_size, and end_of_line from .editorconfig when no explicit Prettier config is present. Check your formatter’s documentation to confirm integration.

Can I have multiple .editorconfig files in a project?

Yes. EditorConfig searches from the file’s directory upward to the root (or until it finds root = true). Deeper .editorconfig files override settings from parent files, letting you define per-subdirectory rules.