Why nginx configs get hard to read at scale

nginx's config grammar is genuinely simple — blocks delimited by `{ }`, directives terminated by `;`, `#` for comments — but that simplicity doesn't stop real-world configs from becoming difficult to read once they accumulate history: inconsistent indentation from different people editing over time, deeply nested location blocks, directives copy-pasted from Stack Overflow with whatever formatting they arrived in. This tool parses the actual grammar rather than just re-indenting the text as-is, which means a config with wildly inconsistent existing indentation still comes out correctly and consistently structured — the output reflects the real nesting the parser found, not whatever indentation happened to already be there.

Structure first, validity second

Making a config's block structure visible — which server block a location actually lives inside, whether a directive is at the http, server, or location level — is a different and more foundational problem than checking whether nginx will actually accept the specific directive names and values used. This tool solves the first problem; for the second, `nginx -t` against the real binary remains the authoritative check, since only the actual nginx binary knows its own current set of valid directives, modules, and value constraints. Seeing the structure clearly first, though, is often what makes it obvious where a misplaced directive or a location block nested one level too deep actually is.