What is EditorConfig and how is it different from Prettier or ESLint?

EditorConfig is a simple, language-agnostic file format that editors and IDEs read natively (many support it built-in; others need a small plugin) to set basic whitespace rules like indent style, indent size, and line endings before a file is even opened. Unlike Prettier or ESLint, it doesn't reformat code on save or lint for style violations, it only sets the editor's baseline typing behavior, so the two are complementary rather than competing.

Why does the file use [glob] sections instead of one flat set of rules?

Different file types often need different rules, for example Makefiles require literal tabs while most source files use spaces, so EditorConfig scopes each block of settings to a glob pattern like [*], [*.md], or [Makefile]. The first matching section (or all matching sections, merged in order) applies to a given file, which is why more specific globs are usually listed after the catch-all [*] section.

What does root = true actually control?

EditorConfig-aware editors walk up the directory tree from the file being edited, merging settings from every .editorconfig file they find, until they hit one with root = true, at which point they stop looking further up. Setting it in your project's top-level .editorconfig prevents an unrelated .editorconfig in a parent directory (for example in your home folder) from also applying.

Do I still need Prettier or ESLint if I have a .editorconfig?

Usually yes. EditorConfig only affects what happens as you type in a supporting editor, it doesn't reformat existing code, enforce anything in CI, or catch a contributor using an editor without EditorConfig support. Most JS/TS projects use .editorconfig for baseline whitespace consistency and layer Prettier and ESLint on top for enforced, tool-checked formatting and linting.

EditorConfig Generator - Build a .editorconfig File

Overview

Introduction

EditorConfig is the file that keeps indentation and line endings consistent across every editor a team uses, before Prettier or ESLint even get involved, by describing basic whitespace rules per file-glob in a plain text format nearly every editor understands natively or with a small plugin.

This tool generates that .editorconfig from a root toggle and one or more glob sections, each with its own indent style, indent size, charset, line-ending, and whitespace-trimming settings.

What Is EditorConfig Generator?

A .editorconfig file generator covering the format's core properties: indent_style, indent_size, charset, end_of_line, insert_final_newline, and trim_trailing_whitespace, scoped per [glob] section.

Supports any number of sections, so a project can set one baseline for [*] and override it for file types with different conventions, like [*.md] (where trailing whitespace can be meaningful) or [Makefile] (which requires literal tabs).

How EditorConfig Generator Works

Each section's glob is validated as non-empty and unique, and its indent size is validated as a whole number between 1 and 16, before being written into the corresponding [glob] block using EditorConfig's plain `key = value` line syntax.

If the root toggle is enabled, `root = true` is written as the first line of the file, followed by a blank line and then each glob section in the order they were added.

When To Use EditorConfig Generator

Use it when starting a new project and you want every contributor's editor to agree on tabs vs. spaces and line endings without relying on everyone's personal editor defaults.

It's also useful when a project's indentation is inconsistent between file types (for example spaces in source files, literal tabs in a Makefile) and you want that difference codified instead of left to chance.

Often used alongside Prettier Config Generator and ESLint Flat Config Generator.

Features

Advantages

Covers every property in the EditorConfig core spec, so the generated file needs no manual additions for standard use cases.
Validates each glob is non-empty and unique and each indent size is a sane whole number, so the output can't contain a broken or conflicting section.
Supports unlimited sections, making it straightforward to give Makefiles, Markdown files, or YAML files their own rules alongside a shared [*] default.

Limitations

EditorConfig only affects editors that support it (natively or via plugin); it has no effect on files edited outside a supporting editor or reformatted by a separate tool.
It doesn't enforce anything in CI on its own, a contributor without EditorConfig support (or a plugin that's disabled) can still commit files that don't follow the rules.

Examples

A typical two-section .editorconfig

Input

root: true, sections: [*] 2-space/lf/utf-8, [*.md] 2-space/lf/utf-8 with trim_trailing_whitespace off

Output

root = true

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

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

Best Practices & Notes

Best Practices

Set root = true in the .editorconfig at your project's root so an unrelated .editorconfig higher up the filesystem (for example in a contributor's home directory) can't unexpectedly apply.
Give [*.md] its own section with trim_trailing_whitespace off, since two trailing spaces are meaningful line-break syntax in Markdown and stripping them silently changes rendered output.
Keep a broad [*] section first for sane defaults, then add narrower overrides like [Makefile] or [*.{yml,yaml}] only where a file type genuinely needs different rules.

Developer Notes

The generator writes sections in the order they're added rather than sorting them, since EditorConfig applies all matching sections in file order (later matches can override earlier ones for the same property), so section order is meaningful and left under the user's control rather than auto-sorted. Indent size is capped at a generous 1-16 range purely as a sanity check; the EditorConfig spec itself doesn't restrict the value, but nothing legitimate needs a wider range.

EditorConfig Generator Use Cases

Setting a consistent indent style and size across a team before any file has been written
Giving Makefiles their required literal-tab indentation without affecting the rest of the project's space-indented files
Preserving Markdown's meaningful trailing whitespace while trimming it everywhere else

Common Mistakes

Forgetting root = true in a project's top-level .editorconfig, letting a stray .editorconfig in a parent directory silently merge in unexpected settings.
Applying trim_trailing_whitespace = true to Markdown files, which strips the two-space hard line break Markdown relies on and silently changes rendered output.

Tips

Use the Prettier Config Generator next for enforced, tool-checked formatting; .editorconfig only guides what happens as you type in a supporting editor.
List more specific globs (like [Makefile] or [*.md]) after the catch-all [*] section so they read as intentional overrides.

EditorConfig Generator