.editorconfig Generator
Generate a .editorconfig with global settings and per-language overrides.
What is editorconfig?
An .editorconfig generator. EditorConfig is the one formatting file every mainstream editor reads — VS Code, JetBrains IDEs, Vim, Emacs, Sublime — which makes it the cheapest way to stop whitespace diffs.
How it works
Global settings are written into a `[*]` block. Each selected language adds a glob block containing only the settings that differ from the global ones, so the file stays short and the intent of each override is obvious: Makefiles need tabs, Markdown needs trailing whitespace left alone, YAML cannot hold tabs at all.
- Paste or fill in the input. Drop in a commit message, a diff, a package.json, a path list or a set of options. The tool reads it locally — nothing is uploaded and no repository is contacted.
- Adjust the rules to match your project. Every linter here takes its convention from a setting you can change: allowed commit types, header length, target branch length, known branch names. Set them once to what your team actually uses.
- Copy the result. Generated files copy straight to the clipboard or download as a real file with the right name (.gitignore, CODEOWNERS, LICENSE, COMMIT_EDITMSG), and Reset returns every field to its default.
Examples
A commit message that fails CI
"Updated(auth): Fixed the expired-token redirect." is rejected by release automation and reported here with the exact reasons: unknown type, capitalised description, past tense and a trailing period.
A .gitignore that only half works
The Checker shows which rule decides a path — and why `!keep.txt` inside an ignored directory never fires, the mistake that sends people to Stack Overflow.
A dependency bump nobody reviewed
The package.json Diff separates added, removed and changed entries per section, so a caret bump of a runtime dependency does not hide inside a lockfile-sized pull request.
A diff pasted from a code review comment
The Diff Viewer understands several `diff --git` blocks, mode-only changes, renames and binary stubs, and calls out a pasted `--stat` summary instead of rendering an empty box.
Common mistakes
Committing a .gitignore without checking it
Rules look right and behave differently: a pattern containing a slash is anchored to the root, a trailing slash means directories only, and a file inside an ignored directory cannot be re-included. Check the paths that matter before you commit the file.
Rewriting published history
A clean commit history is worth having, but amend, rebase and filter-repo change commit hashes. Only rewrite commits that nobody has pulled; after a rewrite, push with --force-with-lease rather than --force.
Treating a generated file as if it were reviewed
These tools produce a starting point, not a decision. Check the licence text against the canonical source, read the security policy before publishing it, and make sure a CODEOWNERS team actually exists — GitHub silently ignores rules whose owner has no write access.
Putting slow checks in a pre-commit hook
A hook that takes 30 seconds gets bypassed with --no-verify within a week, and then it protects nothing. Keep pre-commit to formatting and linting, move type checks and tests to pre-push or CI.
Frequently asked questions
Does .editorconfig change files on its own?
No. It tells the editor how to behave on save — indentation, line endings, final newline. Existing files are only changed when something rewrites them, which is what a formatter or an indentation converter does.
How does it relate to Prettier or ESLint?
They overlap. Prettier reads a few .editorconfig keys, so keeping both in sync avoids an editor fighting the formatter over quotes or indentation; the file is still worth having for languages no formatter covers.
Why does `root = true` matter?
It stops the editor searching parent directories for another .editorconfig file. Without it, a checkout inside a directory that has its own configuration picks up settings you never intended.