.editorconfig Generator: Presets with Round-Trip Parse
An .editorconfig file sits at the repository root and tells each supporting editor how to indent, which line endings to write, and how to encode files on save. The format is a short INI-style document: a root flag, then bracketed glob sections such as [*] or [*.{js,ts}] filled with key = value pairs. Editors look for the nearest file starting at the open file's own directory, then apply the matching sections inside it, with later matches overriding earlier ones for the same option. This page builds that file from language presets and individual controls, and it parses existing files back so problems surface before the next commit.
EditorConfig Builder
Pick a preset, then adjust the controls.Round-trip parser
Paste an existing file to inspect and rebuild it.How It Works
An EditorConfig file has three parts. The root line at the top marks the boundary of the project. Bracketed sections such as [*] or [*.{py,pyi}] hold glob patterns, and each line under a header is one option written as key = value. Editors read the file top to bottom, match sections against the path of the open file, and when several sections match, the later one overrides the earlier option.
The nine keys below cover what editors actually act on. indent_style picks spaces or tabs, indent_size sets the width of one level, and tab_width controls how wide a tab character renders on screen. end_of_line writes lf, crlf, or cr, charset picks the encoding, and the two boolean keys handle trailing whitespace and the final newline. max_line_length draws the ruler, and quote_type guides formatters that rewrite string literals.
- indent_style chooses spaces or tabs, and indent_size sets how many columns one level spans.
- tab_width changes the rendered width of a single tab character without changing the file bytes.
- end_of_line writes lf, crlf, or cr when the editor saves.
- charset picks utf-8, utf-8 with a BOM, or latin1 on save.
- trim_trailing_whitespace and insert_final_newline control the two common cleanup rules.
- max_line_length sets the soft ruler, and quote_type hints at preferred string quotes.
Each preset on this page maps a language convention onto those keys. The Prettier preset uses two spaces across JavaScript, TypeScript, JSON, and CSS. The Python preset adds Black's 88-column limit for .py files, the Go preset switches .go files to real tabs to match gofmt, and the Markdown preset keeps trailing spaces where prose needs hard breaks.
Two details decide whether a saved file behaves as expected. The root flag belongs at the top, before any section header, and an option written inside a bracketed block is scoped to that glob instead of the whole project. When a preset does not match your stack, start from Base and add one section per language that needs different settings.
Before and After: Files This Page Produces
The left block is what the builder prints with the default controls. The right block is a paste that the parser flags, with a rebuilt version offered underneath the report so a cleanup can be copied in one step.
root = true
[*]
indent_style = space
indent_size = 4
end_of_line = lf
charset = utf-8root = true
[*]
indent_style = space
indent_size = 4
indent_size = 2
[*.py]
indent_size = 4Reported: line 5, "indent_size" is set twice here. The later value wins.
Use Cases
| Situation | What to set | Result |
|---|---|---|
| A team mixing VS Code, JetBrains IDEs, and Vim in one repository | A catch-all [*] with indent, line ending, and charset rules | Every save writes the same bytes, so diffs stop carrying whitespace noise |
| A monorepo holding several languages with different formatter defaults | One section per glob, such as [*.go] for tabs and [*.{yml,yaml}] for two spaces | Each toolchain gets its settings without a pile of separate config files |
| Pull request hygiene on a busy open source project | Trim trailing whitespace and insert a final newline on the catch-all | Reviewers see real changes instead of formatting churn |
Common Mistakes
- Skipping the root flag, so a settings file from a parent folder on a contributor's machine quietly overrides the project rules.
- Putting max_line_length on the catch-all and then wondering why prose files wrap at 100 columns. Scope the ruler to code globs instead.
- Setting indent_style to tab while treating indent_size as if it meant spaces. With tabs the number only changes rendered width, so gofmt still writes one tab per level.
- Declaring the same glob twice with different keys. The later block overwrites values without any warning in most editors.
- Turning on trailing whitespace trim globally and breaking Markdown files that rely on two trailing spaces for hard breaks.
- Copying a long preset from another project without checking which keys your editors actually read. Unsupported keys sit in the file with no effect.
Best Practices
- Commit the .editorconfig in the first pull request of a project so every clone starts from the same rules.
- Start from one of the presets here, then delete any section the repository does not need.
- Keep the catch-all small and push language specifics into their own globs, which keeps review of the file quick.
- Match the settings to the formatter already in CI, such as two spaces for Prettier or 88 columns for Black, so the editor and the formatter agree.
- Open a saved file and check the status bar or the IDE EditorConfig view once after editing the file. A typo in a glob looks fine in the text and does nothing.
- Re-run the parser after hand edits. It flags duplicate keys, misplaced root lines, and empty values before teammates pull the change.
Frequently Asked Questions
What does an .editorconfig file do?
It is a plain text file, usually named .editorconfig, placed at the root of a repository. Editors that support the format read it when a file is opened and again before every save, then apply matching indentation, line ending, and encoding rules. The specification stays small: a root flag, bracketed glob sections, and key = value pairs. VS Code, the JetBrains IDEs, Vim, and Neovim all support it through built-in code or a plugin.
How do glob sections and precedence work?
Each header such as [*] or [*.py] holds a glob matched against the path of the file being edited. The [*] section works as the catch-all, and narrower patterns layer on top of it. When several sections in one file match the same path, the later section decides any option it sets. Editors also search upward for the nearest .editorconfig, and the root flag stops that search at your repository boundary.
Which options can this generator write?
The builder covers the nine keys documented on this page: indent_style, indent_size, tab_width, end_of_line, charset, trim_trailing_whitespace, insert_final_newline, max_line_length, and quote_type. The controls expose the ones teams set most often, and leaving the max line length box blank keeps that key out of the output. Custom values such as a 100-column ruler are still accepted as typed. Keys outside this set can be pasted into the parser and read back, with a warning that some editors skip them.
How does the round-trip parser help?
Paste an existing file, press Parse, and the page reports the root flag, the top-level options, and every section with its keys. Problems show up as a list with line numbers: duplicate keys, a root line written inside a section, empty values, and lines that are not key value pairs. The rebuilt block under the report pipes the parsed structure through the same builder, which reorders keys into the canonical sequence and normalizes spacing. Compare the rebuilt text with the original to see what a cleanup would change.
Why does the base preset keep trailing spaces in Markdown?
Markdown turns two trailing spaces at the end of a line into a hard line break, so a blanket trim rule silently rewrites rendered paragraphs. Every preset here sets trim_trailing_whitespace to false for Markdown globs while keeping the trim rule everywhere else. The Markdown preset also sets max_line_length to off, since prose does not benefit from a column ruler. Adjust those sections when your team follows a different Markdown convention.
Should every repository set root = true?
For a normal project the answer is yes. The flag tells the editor to stop looking for another .editorconfig in parent directories, which matters on machines where a home directory file would otherwise leak settings into your project. Nested config files inside a monorepo usually leave the flag off so they extend the root file instead of cutting it off. The builder defaults the checkbox to checked to match that habit.
Does any of this leave the browser?
No. Building, parsing, copying, and downloading all run inside the page, and the tools make no network request with your file contents. The download writes a local Blob named .editorconfig, and the copy button uses the clipboard API after a click. Closing the tab discards the controls, the output, and anything you pasted into the parser.