EditorConfig Generator
Build an .editorconfig file with indent style, line endings, charset and common overrides, in your browser.
How to use
- Choose the indent style and size, end of line, and charset.
- Toggle root, trailing-whitespace, final-newline and the optional overrides.
- Copy the generated file and save it as .editorconfig in your project root.
About this tool
ShowHide
Build an .editorconfig file by choosing the settings rather than remembering the property names: indent style and width, end of line, charset, final newline, trailing whitespace and the per-language overrides that most projects end up needing. The point of the file is that these rules travel with the repository and are read by the editor itself, so a contributor who has never opened your style guide still commits tabs where you use tabs. Two details are worth getting right and easy to miss: the root property at the top stops the search from continuing into parent directories, and section patterns are globs, so [*.md] and [{package.json,.travis.yml}] both work. The result copies out ready to drop at the top of a repository.
Frequently asked questions
What does root = true do?
It marks this as the top-most EditorConfig file, so editors stop looking in parent directories. Put it in your project root and leave it on unless you nest config files.
Why the [*.md] override?
Markdown uses two trailing spaces for hard line breaks, so trimming trailing whitespace would break them. The override disables trimming for .md files only.
Do editors support this out of the box?
Many do (for example JetBrains IDEs and VS Code with the EditorConfig extension). The file is plain INI-style text that any EditorConfig-aware tool reads.
Is anything uploaded?
No. The file is generated entirely in your browser; nothing is uploaded.
Does this replace Prettier or ESLint?
No, it sits underneath them. EditorConfig sets what the editor does as you type — indent, line endings, final newline — while a formatter rewrites the file on save or in CI. Use both, and make sure they agree, because a disagreement shows up as a file that reformats itself back and forth between contributors.
Do the section patterns work like gitignore?
Not quite. They are globs, so [*.md] and [{package.json,.travis.yml}] both work, but there is no negation and a pattern without a slash matches at any depth. Later sections win over earlier ones for the same file, so put the broad [*] block first and the specific overrides after it.
Related tools
EditorConfig Tester
Paste an .editorconfig and some file paths: see the property set each file resolves to, and which section on which line decided every value.
Developer
SQL Formatter
Format and beautify SQL across 10 dialects (PostgreSQL, MySQL, BigQuery, Snowflake, T-SQL …).
Developer
CSS to JS Style Object Converter
Convert a CSS declaration block into a React/JS inline style object, in your browser.
Developer
Git Config Precedence Tester
Paste your git config files and see which value wins for every key, the scope, file and line it came from, what it overrode, and which includeIf fired.
Developer
HTML → JSX Converter
Paste an HTML snippet and get React-ready JSX — class becomes className, onclick becomes onClick, and void tags self-close.
Developer
systemd Service File Generator
Build a .service unit file for systemd — Type, Restart, User, Environment, sandboxing — plus the install and journalctl commands.
Developer