What Is EditorConfig and How to Use It

2 min read by Mohammad Shoeb

What Is EditorConfig and How to Use It

EditorConfig is a small text file named .editorconfig that you drop at the root of your project, and editors read it to enforce consistent formatting for everyone who touches the code. If your team keeps fighting over tabs versus spaces or files keep flipping between LF and CRLF line endings, this is the fix.

What an .editorconfig file does

When you open a file, a supporting editor walks up the folder tree looking for .editorconfig files and applies the matching rules. That means the same indentation, line endings, and character set get used no matter who is editing or which tool they prefer. The settings live in version control next to your code, so a new teammate gets the right behavior the moment they clone the repo.

The format is plain INI. Two things matter at the top:

  • root = true tells EditorConfig to stop searching parent folders. Put it at the very top of your project-level file so outside configs do not leak in.
  • [glob] section headers scope rules to file patterns. [*] matches every file, [*.md] matches Markdown, [*.{js,ts}] matches multiple extensions.

The common keys

A handful of properties cover almost everything teams argue about:

  • indent_style - space or tab.
  • indent_size - number of columns per indent level, like 2 or 4.
  • end_of_line - lf, crlf, or cr. Use lf for cross-platform sanity.
  • charset - usually utf-8.
  • trim_trailing_whitespace - true strips trailing spaces on save.
  • insert_final_newline - true ensures files end with a single newline.

A typical file looks like this:

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

You can hand-write that, or skip the syntax and use the EditorConfig Generator to build it from dropdowns.

How to create one in your browser

  1. Open the EditorConfig Generator.
  2. Pick your indent style and size, line ending, and charset for the [*] block.
  3. Toggle trim_trailing_whitespace and insert_final_newline on.
  4. Add extra [glob] sections for file types that need different rules, such as [*.md].
  5. Copy the output and save it as .editorconfig in your project root, then commit it.

It runs entirely in your browser, so nothing you type is sent anywhere.

Editor support and how it fits with Prettier

Many editors read .editorconfig natively, including those built on VS Code, the JetBrains IDEs, and Visual Studio. Others, such as Sublime Text and older Vim setups, need a small plugin first. Either way, the file itself is identical.

EditorConfig complements Prettier and linters, it does not replace them. EditorConfig handles low-level whitespace and encoding that apply to every file type, while Prettier and ESLint handle language-specific formatting and code-quality rules. Many teams run both, and the two agree as long as your indent settings match.

  • .gitignore Generator - keep junk files out of your repo the same way you standardize formatting.
  • CSS Minifier - strip whitespace from CSS once your source is clean.
  • Diff Checker - confirm a reformat only changed whitespace, not logic.

Add one small file to your repo root and every editor on the team finally agrees.

Developer ToolsHow-to

← All posts