A .env file is simple enough that it's tempting to think there's nothing to get wrong — KEY=value, one per line. Parsing it correctly still means deciding what happens with malformed lines, duplicate keys, quoted values, and comments, and each of those choices affects what comes back out.
Comments and blank lines are parsed, not preserved
Lines starting with # and blank lines are recognized and skipped while parsing — but the formatter re-serializes only the key/value entries it collected, sorted alphabetically. There is no step that puts comments back, because by the time formatting runs, the parser never kept them in the first place. If your .env file has section headers like # --- database config --- above a group of related keys, that structure and those comments are gone after formatting — the keys survive, sorted into a different order, with no memory of which group they came from. If preserving comments matters for your file, this tool is for checking/sorting values, not for round-tripping the file as your source of truth.
Formatting always sorts — that's not optional
Output is sorted alphabetically by key on every run, by design — the stated reason is that alphabetical order makes diffs between two versions of a .env file easier to read in a code review, since keys don't shift position just because a new one was inserted in the middle. The trade-off is that your original ordering (which might have grouped related settings together, unsorted, deliberately) is always discarded. There's no "preserve original order" mode.
A duplicate key is flagged, not silently overwritten
Which value actually takes effect for a duplicate key depends entirely on whatever tool loads your .env file at runtime — some loaders keep the first occurrence, some keep the last, and behavior differs between libraries. This formatter doesn't make that decision for you or silently drop one value; it reports every duplicate as an issue referencing the line the key was first seen on, so you can see the conflict exists and decide which value should actually stay before it becomes a works-on-my-machine bug from two different developers editing the same file.
Quoting is minimal, and only doubles double-quotes
A value only gets wrapped in quotes on output if it contains whitespace or a # character (unquoted, either would be ambiguous or get misread as the start of a comment on re-parsing). When a value does get quoted, only literal double-quote characters inside it are escaped — a backslash in the value isn't separately escaped, so a Windows-style path or a regex pattern containing backslashes passes through as-is rather than being backslash-escaped the way some stricter .env parsers expect.
One malformed line doesn't block the rest of the file
A line that doesn't match KEY=VALUE (missing an equals sign, or a key starting with a digit, which isn't a valid environment variable name in most shells) is collected as an issue and formatting continues past it — the other 49 valid lines in a 50-line file still get formatted. That's the same "collect issues, don't abort" approach this project's OpenAPI validator uses: one bad line shouldn't cost you the ability to see everything else that's fine.