Can this replace nginx -t?

No, nginx -t is the definitive test that runs against your actual NGINX installation with all modules. This tool provides a quick browser-based syntax check for common errors before deploying.

Is my config data secure?

Yes, all validation happens in your browser using JavaScript. Your NGINX configuration is never sent to any server.

What security issues does it detect?

It checks for: missing server_tokens off, potential path traversal in alias directives, missing security headers, unsecured locations, and other common misconfigurations.

NGINX Config Validator

NGINX Configuration

Validation Results

Results will appear here after validation...

What is NGINX Config Validator?

NGINX configuration uses a declarative syntax built on nested blocks (http, server, location), semicolon-terminated directives, and brace-delimited scopes. A single missing semicolon, an extra closing brace, or an unrecognized directive can prevent NGINX from starting — and the error messages are often unhelpful. This validator parses your config text in the browser, checking brace balance, directive spelling, semicolon presence, and common security pitfalls like exposed server tokens, unauthenticated admin locations, and alias path traversal vectors.

How to Use

Paste your NGINX configuration into the text editor on the left.
Click the Validate button to run syntax and security checks.
Errors (red) must be fixed — the config will not load with these present.
Warnings (yellow) indicate security or best-practice concerns that should be addressed.
Info items (blue) are advisory suggestions such as missing security headers.
Re-validate after each round of fixes until no errors remain.

Why Use This Tool?

Catch syntax errors like missing semicolons and unmatched braces before deploying to production

Detect misspelled or unknown directives that would cause NGINX to fail on reload

Identify security misconfigurations including exposed server version tokens and unauthenticated admin paths

Flag potential path traversal vulnerabilities in alias directives within location blocks

Warn about sensitive file exposure (.git, .env) that is not explicitly denied

All validation runs locally in your browser — your configuration never leaves your machine

Tips & Best Practices

Always run nginx -t on the target server after deploying — this browser tool catches common errors but cannot replace the real syntax check against installed modules
Add server_tokens off; in the http block to hide your NGINX version from HTTP response headers and error pages
Use include directives to split large configurations into smaller, reviewable files per site or per function
For SSL hardening guidance, reference ssl-config.mozilla.org for current cipher and protocol recommendations
Consider adding security headers like X-Frame-Options, X-Content-Type-Options, and Content-Security-Policy to every server block

Frequently Asked Questions

What does this NGINX config validator check?

It checks for syntax errors (unmatched braces, missing semicolons), unknown or misspelled directives, structural issues (server blocks without listen directives, missing events or http blocks), and security concerns (missing server_tokens off, unauthenticated admin locations, alias path traversal risks, exposed .git/.env paths, and missing security headers).

Can this tool replace nginx -t on the server?

No. The nginx -t command validates against your actual NGINX installation with all compiled modules and include files. This browser-based tool provides a quick pre-deployment check for common errors and security issues, but it cannot account for third-party modules, environment-specific includes, or runtime variable resolution.

When should I NOT use this validator?

This tool is not designed for validating NGINX stream (TCP/UDP) configs, Lua module blocks, complex if-condition logic with variable nesting, or configurations that rely heavily on map and geo blocks with dynamic resolution. For those cases, nginx -t on the server remains the authoritative check.

Is my configuration data kept private?

Yes. All validation logic runs entirely as client-side JavaScript in your browser. Your NGINX configuration is never sent to any server, API, or third-party service. You can safely validate configs for internal infrastructure without any risk of data exposure.

Why is my directive flagged as unknown?

The validator maintains a built-in list of standard NGINX directives. Directives from third-party modules (such as lua_*, ndk_*, or auth_request_module) may not be in the list and will be flagged as warnings. If the directive comes from an installed module on your server, you can safely ignore the warning.

What security issues does the validator detect?

It checks for: missing server_tokens off (exposes NGINX version), potential path traversal in alias directives where the alias path does not end with a trailing slash, admin location blocks without authentication, .git and .env paths that are not denied, and server blocks that lack common security headers like X-Frame-Options and Strict-Transport-Security.

Real-world Examples

Catching a Missing Semicolon Before Reload

A developer adds a proxy_set_header directive but forgets the trailing semicolon. NGINX would refuse to start, but the validator catches it instantly.

Input

proxy_set_header X-Real-IP $remote_addr
proxy_set_header Host $host

Output

Error: Missing semicolon at end of line (line 1)

Detecting an Unsecured .git Path

A server block serves a Git repository's working directory as the document root, exposing the .git directory. The validator warns that this sensitive path is not denied.