What Is .editorconfig?

The .editorconfig file is a simple configuration file that helps developers maintain consistent coding styles across different editors and IDEs. It can define rules for indentation, line endings, character encoding, trailing whitespace and other basic formatting settings.

Without a shared configuration, developers working on the same project may use different editor settings. One developer may use tabs while another uses spaces, or different editors may save files with different line endings. These differences can create unnecessary changes in version control and make source files harder to maintain.

What Is .editorconfig?

.editorconfig is a plain-text configuration file usually placed in the root directory of a project. It describes basic formatting rules that compatible editors can use automatically when opening or saving files.

The format is intentionally simple and editor-independent. Instead of configuring the same preferences separately in Visual Studio Code, JetBrains IDEs, Vim, Emacs and other tools, a project can store its preferred settings in one shared file.

root = true

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

[*.{js,ts,jsx,tsx}]
indent_style = space
indent_size = 2

[*.py]
indent_style = space
indent_size = 4

Why Use .editorconfig?

The main purpose of .editorconfig is to eliminate small differences in editor configuration that can accumulate across a team. The file becomes part of the repository, so every contributor can use the same baseline settings.

• Keep indentation consistent.
• Standardize line endings.
• Define the expected character encoding.
• Remove unnecessary trailing whitespace.
• Ensure files end with a newline.
• Reduce formatting-only changes in Git.
• Make new contributors' editor setup easier.

How .editorconfig Works

When a developer opens a file, a compatible editor looks for an .editorconfig file and determines which rules apply to that file. The rules are selected using section patterns such as [*], [*.js] or [*.{js,ts}].

The editor then applies the supported properties to the file. Some properties affect how new content is inserted, while others control how files are saved. The exact behavior depends on the editor and its level of EditorConfig support.

Project
  |
  +-- .editorconfig
  |
  +-- src/
  |    +-- app.ts
  |    +-- utils.ts
  |
  +-- scripts/
       +-- build.py

Editor opens app.ts
        |
        v
Matches [*.ts]
        |
        v
Applies indentation and formatting rules

The root Property

The root property tells an EditorConfig-aware editor that this is the top-level configuration file for the project. When root is set to true, editors should stop searching for additional .editorconfig files in parent directories.

root = true

EditorConfig Sections

EditorConfig uses sections to determine which files a group of properties applies to. A section is written inside square brackets and contains a file pattern.

The Wildcard Pattern

The [*] pattern is commonly used as the general configuration section. Rules inside this section provide defaults for files throughout the project unless another matching section overrides them.

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

Indentation Settings

One of the most common reasons to use EditorConfig is to standardize indentation. The indent_style property defines whether indentation uses spaces or tabs, while indent_size specifies the number of spaces used for one indentation level when spaces are selected.

[*.js]
indent_style = space
indent_size = 2

[*.py]
indent_style = space
indent_size = 4

These settings do not replace language-specific formatters such as Prettier or Black. Instead, they provide a basic editor-level convention that can complement those tools.

Character Encoding

The charset property defines the character encoding that an editor should use when working with a file. UTF-8 is the most common choice for modern web and software projects because it supports a wide range of characters while working well across platforms.

[*]
charset = utf-8

Line Endings

Different operating systems traditionally use different line-ending sequences. Windows commonly uses CRLF, while Linux and macOS commonly use LF. A project containing files with mixed line endings can produce unnecessary changes in Git and make diffs harder to review.

[*]
end_of_line = lf

Using LF throughout a cross-platform project is common, but the appropriate choice depends on the project's existing conventions and tooling.

Trailing Whitespace

Trailing whitespace consists of unnecessary spaces or tabs at the end of a line. It usually has no effect on program behavior but creates noisy diffs and can make source files harder to inspect.

[*]
trim_trailing_whitespace = true

Markdown files are a notable exception because trailing spaces can have formatting meaning in some Markdown implementations. Projects that rely on this behavior may choose different settings for Markdown files.

[*.md]
trim_trailing_whitespace = false

Final Newlines

The insert_final_newline property controls whether files should end with a newline character. Keeping a final newline is a common convention in source repositories and is supported by many development tools.

[*]
insert_final_newline = true

File-Specific Rules

A project does not have to use identical settings for every file type. Different languages and file formats can have different indentation requirements, making file-specific sections useful for mixed-language repositories.

root = true

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

[*.{js,ts,jsx,tsx}]
indent_style = space
indent_size = 2

[*.json]
indent_style = space
indent_size = 2

[*.py]
indent_style = space
indent_size = 4

[Makefile]
indent_style = tab

A Practical Web Project Example

A typical JavaScript or TypeScript project can use a relatively small .editorconfig file. The goal is not to duplicate every formatting rule used by the project's linter or formatter, but to establish predictable editor behavior.

root = true

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

[*.{js,jsx,ts,tsx}]
indent_style = space
indent_size = 2

[*.json]
indent_style = space
indent_size = 2

[*.md]
trim_trailing_whitespace = false

EditorConfig and Git

.editorconfig is not a Git configuration file, but it works especially well with Git-based workflows. Because the configuration is stored in the repository, every contributor can use the same basic formatting conventions.

Consistent line endings and whitespace can also reduce meaningless changes in Git diffs. This makes code reviews easier because reviewers can focus on actual source changes instead of formatting differences caused by individual editor settings.

EditorConfig vs Prettier

EditorConfig and Prettier solve related but different problems. EditorConfig provides a basic cross-editor configuration standard, while Prettier is a code formatter that actively transforms source code according to formatting rules.

A project can use both. EditorConfig establishes general file conventions, while Prettier handles language-specific formatting such as spaces around operators, quotation marks, trailing commas and line wrapping.

EditorConfig vs ESLint

ESLint focuses primarily on JavaScript and TypeScript code quality, correctness and style rules. EditorConfig operates at a more general file and editor configuration level and can apply to many different file types.

Where Should .editorconfig Be Stored?

The usual location is the root directory of the repository. This makes the configuration easy to discover and allows it to apply to the entire project.

my-project/
├── .editorconfig
├── .gitignore
├── package.json
├── src/
└── README.md

Do You Need an Editor Plugin?

Many popular editors and IDEs provide built-in EditorConfig support, while others can use a plugin. Before relying on a particular property, check whether the editor used by your team supports it.

EditorConfig defines a common configuration format, but support for individual properties can vary. A project should therefore avoid assuming that every editor will interpret every possible setting identically.

Common Mistakes

• Forgetting to commit .editorconfig to the repository.
• Using conflicting indentation rules for the same file type.
• Changing line-ending settings without considering existing files.
• Duplicating formatter configuration unnecessarily.
• Assuming every editor supports every property.
• Adding complex rules that provide little practical benefit.
• Using different project conventions without documenting why.

Best Practices

• Keep .editorconfig in the repository root.
• Use root = true for the main project configuration.
• Define UTF-8 unless the project has a specific requirement for another encoding.
• Choose one line-ending convention for the project.
• Set consistent indentation rules for each language.
• Enable a final newline for source files.
• Remove unnecessary trailing whitespace.
• Use separate sections when different file types need different settings.
• Let dedicated formatters handle language-specific formatting.
• Keep the configuration simple and easy for contributors to understand.

A Minimal .editorconfig

Not every project needs a large configuration. A small file can already solve the most common cross-editor inconsistencies.

root = true

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

A More Flexible Configuration

Projects containing several programming languages can define shared defaults and then override individual properties for specific file types.

root = true

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

[*.{js,jsx,ts,tsx}]
indent_style = space
indent_size = 2

[*.css]
indent_style = space
indent_size = 2

[*.py]
indent_style = space
indent_size = 4

[*.go]
indent_style = tab
tab_width = 4

[*.md]
trim_trailing_whitespace = false

Frequently Asked Questions

Helpful Development Tools

An .editorconfig Generator helps create consistent EditorConfig files for different project types, a Gitignore Builder generates ignore rules for repositories, a Docker Ignore Generator creates .dockerignore files for container builds, a Package.json Formatter helps format package configuration files, and an Environment Variable Formatter helps organize environment variable configuration.

Conclusion

.editorconfig is a small but useful part of a well-organized development project. It provides a shared baseline for indentation, line endings, encoding, whitespace and other editor-related settings without tying the project to one specific development environment. By committing a simple .editorconfig file to the repository and combining it with tools such as formatters and linters, teams can reduce unnecessary formatting differences, keep Git diffs cleaner and make collaboration more predictable across different editors and operating systems.