.editorconfig Generator

Build .editorconfig files with per-language settings for indent style, charset, and line endings.

Tested tool guide Tested browser tools Checked August 16, 2026

What .editorconfig Generator does and how it behaves

Create the contents of an .editorconfig file by choosing indentation, character encoding, and line-ending rules for all files or selected filename patterns. Language-specific settings are expressed as glob sections such as [*.js], not by inspecting source code or detecting a programming language. That distinction is easy to miss: a rule applies because a file path matches its section pattern. The generated configuration guides compatible editors, but it does not itself reformat existing files.

How the result is produced

Sections and properties

The generator expresses shared choices in a broad section such as [*] and places narrower choices in sections associated with filename patterns. Each section contains EditorConfig properties such as indent_style, indent_size, charset, and end_of_line. A property omitted from a section is not automatically reset there; another matching section or an EditorConfig file higher in the directory tree may still supply it.

Configuration lookup

For a source file, EditorConfig-aware software looks for .editorconfig files from that file's directory toward parent directories. A root = true declaration stops that upward search. The effective settings depend on the source file's location, every applicable section pattern, any nearer .editorconfig files, and which EditorConfig properties the particular editor or integration supports.

Good uses

Starting a repository with spaces, a fixed indentation width, UTF-8 text, and LF line endings while recording those choices in a standard project file.
Giving Makefiles a tab-based indentation rule while keeping space indentation for JavaScript, JSON, CSS, or other filename groups in the same repository.
Creating separate line-ending or indentation sections for file types that follow different conventions, without copying editor-specific preference files for every contributor.

Limits and checks

A section label represents a glob pattern, not semantic language recognition. Generated settings for [*.js] affect matching filenames even when their contents are not JavaScript, and do not affect JavaScript stored under a different extension.
The file must be placed at the intended directory level. A correctly formed configuration in the wrong directory may govern only part of a repository, or may not be discovered for the files being edited.
EditorConfig communicates preferences to supporting software; it is not a formatter or repository-wide conversion result. Unsupported properties may be ignored, and existing whitespace or line endings normally remain until another program rewrites the file.

Common questions

What does root = true change?

It tells EditorConfig-aware software to stop searching parent directories after reaching that .editorconfig file. This prevents an unrelated configuration above the project from contributing settings. It does not make every section match every file, and it does not prevent a more deeply nested .editorconfig from supplying or overriding settings for files beneath that nested directory.

Will the generated file immediately reformat my source files?

No. The result is configuration text, not a transformed copy of the repository. A compatible editor, formatter, or other integration may apply the declared indentation, charset, or end-of-line preference when it opens, edits, or saves a matching file. Exact behavior still depends on that program, including whether it changes existing content automatically or only affects new edits.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.