EditorConfig Generator

What is an .editorconfig file?

An .editorconfig file tells every editor on a project to agree about the boring things: tabs or spaces, how many of them, which line ending, whether to trim trailing whitespace. It sits in your repository, most editors read it without a plugin, and it settles arguments that would otherwise be relitigated in every code review.

The format is deliberately small. A section header is a glob in square brackets, the lines under it are property assignments, and a file at the top of your project marks itself with root = true so the search stops there. That is nearly all of it, which is why people write one in a minute and then wonder for an hour why a particular file is not picking up the settings they expected.

This tool does both halves. You edit the file on the left, and underneath you give it a path and it tells you exactly which section supplies each property — because that is the question a .editorconfig cannot answer just by being read.

How to use it

1. Start from the file shown. It is a sensible default with the properties most projects want. Edit it directly — add sections, change values, delete what you do not need.
2. Type a path to test. Relative to wherever the .editorconfig lives, with forward slashes. Try one of your awkward files: the one you suspect is not getting the settings you meant.
3. Read which section won. Every applied property is listed with the glob that supplied it, and every matching section is shown with how many of its properties survived. Anything that departs from the specification is flagged underneath.

Later wins, and specificity counts for nothing

This is the rule that costs people an afternoon. When two sections both match a file, the one written later in the file supplies the value. How specific the pattern looks plays no part whatsoever — there is no scoring, no most-specific-match, none of the machinery CSS or routing tables have taught you to expect.

So a broad section at the bottom of the file silently overrides the careful per-language sections above it. If you add a general tidy-up rule to the end of a long .editorconfig, you have just changed the behaviour of everything above it for any property you set. The checker on this page shows exactly that: each matching section reports how many of its properties actually survived to the final answer.

Between files the direction reverses, which is worth holding in your head separately. An editor starts at the file being edited and walks up the directory tree, reading the closer files last so that they win, and stops as soon as it reaches one declaring root = true. Forget that line and a .editorconfig in a parent directory — or in your home folder — keeps applying to your project.

The glob syntax is not gitignore's

The patterns look like gitignore's and they are not, which is the second reliable source of surprise. Alongside the familiar asterisk and question mark, both of which stop at a directory separator where a double asterisk does not, EditorConfig has brace alternation and something gitignore has never had: an integer range. The pattern file{1..3}.txt matches file2.txt but not file4.txt, and either bound may be negative.

That range has a catch, and it fails silently. The first number must be smaller than the second, so {3..1} is not a range at all and matches those five characters literally. Nothing warns you. The same trap sits in a single-element brace: {s1} matches a file actually called {s1}, not one called s1, and the specification says so in a parenthesis that is easy to read past.

Square brackets are stricter than they look, and this one caught out the reference implementation as well as this tool. The specification says every character inside brackets is literal — so [a-c] is the three-character set a, hyphen and c, and does not match b. Almost every other pattern language in the world reads a-c as a range, which is exactly why it is worth knowing that here it does not.

Finally, whether a glob contains a slash decides how far it reaches. A pattern with one is measured from the directory holding the .editorconfig; a pattern without may match at any depth below it. That is why [*.py] covers your whole tree while [src/*.py] covers exactly one directory.

Honest limitations

This page implements the specification, and editors do not implement it uniformly. The seven properties here are the ones the specification defines and that support is broadly reliable for, but an editor is free to ignore any of them, and several popular ones need a plugin before they read the file at all. If a setting is not taking effect, check that your editor supports that property before assuming the file is wrong.

The checker also works on the file in front of it. Real projects can have several .editorconfig files at different depths, and the resolved answer for a path depends on all of them plus where the search stops. What is modelled here is one file and the rules within it, which is where the confusing part almost always lives.

One thing found while building this is worth passing on: the reference implementation and this tool disagree on bracket expressions containing glob characters, and the specification sides against the reference. Its own worked example is a pattern the reference gets wrong. It is a corner nobody writes on purpose, but it is a reminder that a config format's edge cases are decided by whatever your editor happens to ship.

Why is it free?

It all runs in your browser. Matching a path against a glob costs nothing on your own machine, so there is no server to pay for and no reason to ask you for an account.

Nothing you type is uploaded, stored or logged. Directory layouts and file names say a good deal about a private codebase, and the reliable way to keep that private is not to send it anywhere.