Nginx Config Validator

Validate nginx configuration files for syntax errors and common misconfigurations.

Nginx Configuration

Drop a .conf file or click to browse

Nginx Config Validator

This client-side validator checks nginx configuration files for common syntax problems without needing to run nginx -t on a server. It detects unbalanced braces (a common cause of nginx refusing to start), directives that appear to be missing a trailing semicolon, empty blocks, duplicate root directives within a block, proxy_pass lines without semicolons, and common typos like server_names or locaton. For production use, always run the official nginx -t command on your server as the final validation step. All processing happens in your browser — no configuration data is uploaded.

Built and maintained by Meet Shah · Last updated 24 July 2026

What this tool is used for

Catching an unbalanced brace before reloading a server and taking a site down.
Checking a config generated by a template for a directive in the wrong context.
Reviewing a change from a colleague when you have no server to test against.
Spotting a missing semicolon in a long file quickly.
Sanity-checking a snippet from a blog post before pasting it into production.

Frequently Asked Questions

What does it check?: Structure, not semantics: balanced braces, directives ending in a semicolon, blocks that are opened and never closed, and stray closing braces. Comments are stripped and quoted strings blanked first, so a `{` inside a string or a `#` inside a URL does not confuse the count.
Does it replace nginx -t?: No, and nothing in a browser can. `nginx -t` loads the real config with your real modules, resolves `include` globs, checks that certificate files exist and that directives are valid in their context. Use this to catch a typo before you deploy, and `nginx -t` before you reload.
Why does nginx complain a directive is not allowed here?: Because every directive has a set of contexts it is legal in. `root` works in `http`, `server` and `location`; `listen` only in `server`; `worker_processes` only at the top level. Copying a line from a blog post into the wrong block is the most common nginx error there is.
What is the most dangerous config mistake?: A missing semicolon is merely fatal at load time. The genuinely dangerous one is silent: `location /api` matching more than you expect, or an `if` block — nginx's own documentation warns that `if` inside `location` is evaluated in ways that surprise almost everyone.
How do I apply a change safely?: `nginx -t` first, then `nginx -s reload`, which starts new workers with the new config and lets the old ones finish their connections. A reload never drops traffic; a `restart` does, and it fails outright if the config is broken.

Common errors and gotchas

Treating a syntax pass as a working config. Valid syntax can still route to the wrong place.
Putting a directive in the wrong block, which parses but is ignored or applies far more broadly than intended.
Forgetting a semicolon, which makes the error appear on a later line than the mistake.
Assuming an included file is checked. Includes are resolved by the server, not by a text-level check.
Relying on this instead of the server's own test command, which is the only authority on its own config.