CFG File Documentation

Summary

A configuration file with the .cfg extension stores settings that tell a program, game, or device how to behave. It has no single owner or format: most are plain text in key=value or INI-style sections, readable in any code editor, while a minority are an application’s private binary layout. There is no standard MIME type; text ones are served as text/plain. Always copy the file before editing, because a wrong value can stop the program from starting.

Technical details

Feature	Value
Full name	Configuration file (generic)
File extension	`.cfg`
MIME type	`text/plain` (text variants); none defined
Category	Settings file
Format type	Application-defined — usually text, sometimes binary
Common structure	`key=value` lines, often grouped in `[Section]` headers
Comment markers	Lines starting with `;` or `#` (convention)
Developer	None — reused by thousands of unrelated programs
Magic number	None — identified by which program created it
Open standard	No — no governing specification
Created by	The program, when you change its options
Read by	That same program, at startup
Typical location	The app’s install or profile/settings folder
Safe to delete	Usually — the app regenerates defaults (custom settings are lost)
Related extensions	`.ini`, `.conf`, `.config`, `.json`, `.yaml`

What is a CFG file?

CFG is short for configuration, and a .cfg file holds the settings that control how a program, game, operating-system component, or piece of hardware behaves. It is a generic extension, not a defined format: there is no CFG standard, no governing body, and no version history, because thousands of unrelated applications independently chose .cfg for their own settings. What a given .cfg contains depends entirely on the program that wrote it. The convention has been in use since the DOS and early-Windows era, and it never had a single origin.

Because .cfg is not one format, this page cannot describe a fixed byte layout, header, or magic number — none exists across the extension as a whole. What it can do is explain what these files actually are, how the common text form is structured, how to tell a text .cfg from a binary one, and how to edit one without breaking the program that depends on it.

How a program creates and reads its .cfg

A .cfg file is written by an application, not by a user opening a “new configuration” document. When you change an option in a program’s settings, the program serialises the new value into its .cfg; at the next startup it reads the file back and restores your choices. The file therefore lives wherever that application keeps its state: inside a game’s install directory, in a per-user profile folder, or exported by hand from a router or switch. Identify the owner of a stray .cfg by the folder it sits in, or by opening it as text and reading the option names and comments inside.

This is also why deleting a .cfg is usually recoverable: most programs regenerate a default configuration if the file is missing. You lose your customisations, but the application still starts. The exception is a file that stores something the program cannot rebuild (a licence token, a saved profile), so check what the file holds before removing it.

The key=value and INI structure

The large majority of .cfg files are plain text in a simple key=value or INI-style layout. That format is human-readable, which is exactly why hand-editing a .cfg is so common in PC gaming and network administration.

# graphics.cfg  (lines starting with # or ; are comments)
[Display]
resolution_width=1920
resolution_height=1080
fullscreen=true
vsync=0

[Input]
mouse_sensitivity=2.5
invert_y=false

The pieces are consistent across most text configs. A [Section] header in square brackets groups related settings (optional, and not every file uses them). Each key=value line is one setting: an option name, an = (or sometimes : or whitespace), and its value, which may be a number, a boolean written as true/false or 0/1, a quoted string, or a file path. Lines beginning with ; or # are comments the program ignores. There is no schema enforcing any of this — each application decides its own key names and value types, so a value that is valid for one program is meaningless to another.

Telling a text .cfg from a binary one

A minority of applications save .cfg in a proprietary binary format rather than text. Some games, CAD and engineering tools, and hardware utilities pack their settings into an application-specific binary layout with no documented structure. Opened in a text editor, a binary .cfg shows garbled characters, null bytes, and unreadable runs — the sign that only the originating program can read or change it safely. The quickest test is to open the file in a code editor: if you can read option names and values, it is text and you can edit it; if it is a wall of gibberish, close it and change those settings through the program’s own options instead. There is no reliable general converter for a binary .cfg, because its layout is defined solely by the app that wrote it.

CFG, INI, CONF and CONFIG

The names .cfg, .ini, .conf, and .config are near-interchangeable in practice: all are common labels for a plain-text settings file, and many .cfg files are already INI-formatted. The extension is a convention the developer picked, not a different structure. That has a practical consequence for “converting” a .cfg: renaming file.cfg to file.ini or file.txt only changes the label, and the program that reads the .cfg will no longer find it under the new name. There is no meaningful conversion to JSON or XML either, because an arbitrary key=value config has no fixed schema to map onto a structured format, and the original program would not read the result. Related plain-text settings formats worth knowing are INI and YAML.

Frequently asked questions

Why does my .cfg file look like random characters?

That application saves its configuration in a proprietary binary format instead of text, so a text editor cannot display it meaningfully. Do not try to edit the garbled text — change those settings through the program’s own options, which write the binary file correctly.

I edited a .cfg and now the program won’t start. What now?

Restore the backup you made before editing. If you did not make one, delete the .cfg so the program regenerates a default configuration — you lose your custom settings but the application should start again. This is exactly why copying the file first matters.

References

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

Table of contents