EditorConfig Not Working | Fixes That Stick Today

You saved a .editorconfig, hit format, and nothing changed. Tabs still show up. Line endings still flip. A teammate commits a file and your diff turns into confetti.

This guide helps you find the exact reason your rules aren’t being applied, then lock things down across popular editors. You’ll start with fast checks, then move into editor-specific fixes, Git settings, and a clean template you can paste into your repo.

Why EditorConfig Rules Get Ignored

EditorConfig is simple when it’s working. When you open a file, the editor looks for a file named .editorconfig in the file’s folder, then keeps walking up parent folders. It stops at the drive root or when it finds root=true. Newer matching rules override earlier ones. That search behavior is described at EditorConfig.org.

When things break, it’s rarely random. It’s usually one of four buckets: the config can’t be found, the rule block doesn’t match the file, a plugin/extension isn’t active, or another formatter rewrites the file after the editor applies settings.

Symptom	Likely Cause	Fast Check
Indent stays wrong	Glob pattern doesn’t match	Verify the section header covers the file type
Line endings keep changing	Git rewrites endings	Review autocrlf and .gitattributes
Works for one dev only	Editor integration differs	Check plugin/extension enabled state
Rules apply only after save	Editor applies on save	Save, then re-check whitespace changes

Placement And Naming Checks

Start with the boring checks. They fix a lot of “nothing happens” cases.

• Confirm the filename — It must be exactly .editorconfig, not editorconfig, not .editorconfig.txt, and not a different case on systems that care.
• Put one at the repo root — A root file keeps behavior consistent across nested folders and mono-repos.
• Add root=true — Put it near the top so a config above your repo can’t override your settings by accident.
• Open a real file tab — Many editors resolve settings per open file, not just per open folder.

Pattern Matching Traps

If the section header doesn’t match, the rules won’t apply. Tiny glob mistakes can waste hours.

• Check brace globs — [*.{js,ts}] matches JS and TS. A stray brace or missing comma can make the whole block miss.
• Keep patterns readable — If you can’t glance at it and know what it matches, it’s easy to ship a silent bug.
• Test with one obvious rule — Set indent_size for one file type you can verify in seconds, then expand.

Formatter Conflicts

Even when EditorConfig loads, another tool can rewrite the file right after. Prettier, ESLint fixes, Black, gofmt, and IDE “Reformat” actions may ignore EditorConfig or use only parts of it.

• Disable format-on-save briefly — Save a file with a deliberate trailing space and see if it gets trimmed by EditorConfig alone.
• Check the default formatter — In some editors, a default formatter runs after whitespace rules are applied.
• Align one source of truth — Let EditorConfig handle whitespace basics, then let your language formatter handle code layout.

EditorConfig Not Working In VS Code On Save

If you’re using VS Code, the most common cause is simple: you don’t have the EditorConfig extension active in the workspace you’re editing. Many setups rely on an extension for EditorConfig behavior, and some settings apply only on save.

Install And Verify The Extension

1. Install the EditorConfig extension — Search Extensions for “EditorConfig” and install the one listed as “EditorConfig.” The marketplace listing explains activation and supported properties: EditorConfig for VS Code.
2. Reload the window — Use Reload Window so the extension re-initializes cleanly after install or update.
3. Trust the folder — If the workspace is untrusted, VS Code can limit extension behavior until you trust it.

Stop Settings From Fighting Each Other

VS Code can apply whitespace rules from multiple places. The cleanest setup is one place for whitespace defaults and one place for code formatting.

• Remove hardcoded tab settings — If you pin tab size or insert spaces in user/workspace settings, you can get confusing flips.
• Set one formatter per language — If you use Prettier for JS, keep it, then match its indent setting to your .editorconfig.
• Check workspace settings.json — Repo settings can override user settings, so teammates may see different behavior until aligned.

Confirm You’re Editing The Right Root

Multi-root workspaces can trick you. The active file might belong to a different root than the config you’re editing.

1. Open the repo root folder — Use Open Folder on the true repository root, not a subfolder like src.
2. Search for extra .editorconfig files — A closer file can override the root file for a sub-tree.
3. Check nested root=true — A nested config with root=true stops the search early and can block your top-level rules.

Fixes For Visual Studio And .NET Projects

Visual Studio reads EditorConfig files deeply for .NET code styles, including analyzer settings, and it can generate config entries from its code style options. Microsoft documents the workflow and behavior on Microsoft Learn: Define consistent coding styles with EditorConfig.

Create The File Cleanly

If adding the file through the IDE UI fails, create it manually and then include it in the solution so it’s visible to the whole team.

1. Create .editorconfig at the solution folder — Use your file explorer, then add it to the solution so it shows up in Solution Explorer.
2. Put root=true near the top — This blocks parent configs from affecting your repo rules.
3. Commit it to Git — If it isn’t tracked, you’ll chase “works on my machine” forever.

Know Which Rules Apply Where

In .NET land, some rules apply to analyzers, some to formatting, and some to both. If a rule seems ignored, it can be a naming issue or a scope issue.

• Verify the exact rule name — Analyzer entries are picky about identifiers; a small typo can make a line inert.
• Check file patterns — A rule in a [*.cs] block won’t touch .fs or .vb files.
• Watch per-folder overrides — A second config under a project folder can override the root settings for that project.

Clear Stale State

If you added a new config and still see no change, clear the editor state before you keep tweaking the file.

• Restart Visual Studio — It clears cached state after adding new config files or changing large rule sets.
• Disable extra format steps — A build step, hook, or extension that reformats files can hide the real behavior.
• Validate encoding settings — If you set charset, confirm the file type and the editor are aligned.

Fixes For JetBrains IDEs

In JetBrains IDEs, EditorConfig behavior depends on the EditorConfig plugin being enabled. JetBrains documents how to enable it and how the IDE reads rules here: EditorConfig in IntelliJ IDEA.

Enable The Plugin And Restart

1. Open the Plugins screen — Use the IDE settings dialog, then go to Plugins and search for “EditorConfig.”
2. Enable the plugin — Toggle it on if needed, then restart the IDE so it loads correctly.
3. Confirm project settings aren’t masking it — Per-project code style settings can make changes look inconsistent until aligned.

Apply Rules To Existing Files

EditorConfig sets how new edits are written. Existing files won’t always “snap” into compliance until you run a reformat action.

• Reformat a folder intentionally — Reformat the project root, then review the diff before committing so you don’t ship surprise churn.
• Start with whitespace-only rules — Indent, trailing whitespace, and final newline are safer to apply across a whole repo.
• Keep patterns tight — If only one module should have a special style, scope the block to that folder pattern.

Git Settings That Keep Diffs Clean

Sometimes the editor is fine and Git is the thing rewriting files. If you’re searching because editorconfig not working feels like “line endings never stay put,” Git settings are often the reason.

Line Endings And .gitattributes

Pick a rule set, write it down in the repo, and make it consistent across file types. This prevents one machine from rewriting what another machine just saved.

• Decide on LF or CRLF — Many repos store LF in Git to keep merges predictable, even when devs use Windows.
• Add .gitattributes — Use it to lock endings per file type so merges stop producing noisy diffs.
• Check core.autocrlf — A global Git setting can silently rewrite endings; align your team on one value.

Keep Automation Predictable

Automation is only helpful when it’s fast and clear. If it surprises people, they’ll disable it.

1. Run format checks in CI — Let CI fail with a clear message when formatting drifts, then point to the exact fix command.
2. Use hooks carefully — If a hook rewrites files, make it quick and show what changed so the commit isn’t confusing.
3. Limit scope when needed — Blocking trailing whitespace in generated files can be noisy; exclude generated folders if that matches your repo reality.

A Clean .editorconfig Template You Can Paste

This template covers common defaults without being harsh. Save it as .editorconfig at the repo root, commit it, then verify behavior in each editor you use.

root = true

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

[*.md]
trim_trailing_whitespace = false

[Makefile]
indent_style = tab

[*.{cs,fs,vb}]
indent_size = 4

[*.{js,jsx,ts,tsx,json,yml,yaml}]
indent_size = 2

Extend The File Without Surprises

You don’t need a huge config. You need rules that match your repo and behave the same across tools.

• Add one block at a time — Make a change, test it on a real file, then commit so you can track what changed and why.
• Keep the [*] block steady — Put defaults like indentation and line endings there so every file starts from the same baseline.
• Override only for real needs — Markdown often keeps trailing spaces for line breaks. Makefiles often require tabs.

Quick Self-Test After You Commit

Do a fast test per editor setup. It catches issues before you burn an hour tweaking patterns.

1. Open a file that matches a clear block — Pick a file type with an obvious indent_size rule in your config.
2. Make a tiny whitespace change — Add a trailing space or adjust an indent, then save.
3. Check the diff in Git — If the saved result matches the rule and the diff looks clean, the config is being applied.

If you still see editorconfig not working behavior after these steps, isolate the editor layer: turn off format-on-save, confirm the config is found, then re-enable tools one by one until the conflict shows itself.