All tools

.editorconfig Validator

Code

Parse an .editorconfig file into its root flag and glob sections, and flag structural mistakes: unknown properties, invalid values for known properties, a root declaration outside the preamble, and duplicate properties within a section

Paste an .editorconfig file and see it broken down into its root flag and each glob section's properties, with every syntax mistake called out by line number. It catches the errors that quietly stop an editor from applying your settings, like an indent_style value that isn't tab or space, a root declaration placed after a section instead of at the very top, or a line missing its equals sign. Softer issues, like an unrecognized property name or a property repeated twice in the same section, are flagged as warnings so you can tell what's actually broken from what's just untidy.

editorconfigconfigvalidatorlinting

How to use .editorconfig Validator

  • 1.Paste the contents of your .editorconfig file into the input box.
  • 2.Review the issues list: errors mean an editor will likely ignore or misread that line, warnings are unusual but not necessarily wrong.
  • 3.Check the sections panel to confirm each glob's properties match what you intended, including which section root applies to.

Frequently asked questions

Does this check my editor's actual behavior?
No, it only validates the file's syntax and known property values against the EditorConfig spec. It doesn't run inside a real editor, so plugin-specific properties some editors support beyond the spec are flagged as unknown.
What counts as an error versus a warning?
Errors are things that break parsing or produce an invalid value for a known property, like a malformed line or indent_size set to something that isn't a number or "tab". Warnings are softer issues like an unrecognized property name or a duplicate property in the same section, which don't stop the file from being read.
Why did root after a section get flagged as an error instead of a warning?
The EditorConfig spec requires root to appear in the file's preamble, before any section header. A tool reading root after a section is likely to ignore it, so this validator treats that placement as an error rather than a style nit.
Does it validate glob patterns against real file paths?
No, it checks that a section header is syntactically a bracketed pattern, but it doesn't simulate glob matching against any specific file. Use it to check the file's structure, not to predict which section applies to a given path.

Use via API, SDK, or MCP

cURL# Free: 1,000 req/day · Pro: 10,000 req/day
curl -X POST https://api.utilix.tech/v1/tools/editorconfig-validator \
  -H "Authorization: Bearer utx_live_..." \
  -H "Content-Type: application/json" \
  -d '{"text":"root = true\n\n[*]\nindent_style = space\nindent_size = 2\nend_of_line = lf\n"}'

Get an API key from your dashboard · Full API docs →