What Compose versions are supported?

The validator checks against the published Compose schemas, which include the legacy version 1 format, the 2.x family, and the 3.x family. Each version has slightly different features and constraints — v3 added Swarm-specific 'deploy' keys, dropped some v2 features like 'extends', and changed the network model. The validator warns about deprecated features and flags options that don't exist in whichever version you're targeting.

Will it catch all errors?

It catches most syntax and schema errors, which is the bulk of what goes wrong with compose files. What it can't catch are runtime issues — an image name that doesn't exist on the registry, a Dockerfile that fails to build, a port conflict that only manifests when something else is already bound to that port, a container that starts but immediately exits because of an application error. Static validation handles structure; runtime testing handles operational behavior. You need both.

Should I validate in CI?

Yes, basically always. Adding a validation step to your pipeline catches issues before deployment, which saves real debugging time and prevents broken configs from reaching production. GitHub Actions, GitLab CI, Jenkins, and the others all make this trivial — typically a one-line job that runs the validator and fails the build if it finds problems. The faster the feedback to developers, the cheaper the fix.

What's the difference between v2 and v3?

Version 3 added Docker Swarm orchestration support through 'deploy' keys, expanded networking options, and the ability to deploy compose files as Swarm stacks. It removed some v2 features like 'extends' and 'volumes_from'. Use v2 if you're running traditional Compose without orchestration; use v3 if you're targeting Swarm or want the modern feature set. The validator supports both, so picking the wrong one mostly just produces clear error messages rather than silent failures.

How do I validate via command line?

Browser-based validators are convenient for one-off checks. For CLI validation, the built-in 'docker-compose config' (or 'docker compose config' in the new CLI) parses your file, validates it, and outputs the canonical form. Adding '--quiet' suppresses the output and just gives you a pass/fail exit code, which is what you want in CI scripts and automated testing pipelines.

What about secrets in compose files?

Better validators flag inline secrets as a warning — environment values that look like high-entropy passwords or API keys shouldn't be hardcoded in a file that's likely going into version control. Use environment files (.env) excluded from git, Docker's built-in secrets feature for Swarm, or an external secret manager. The validator can't tell whether a value is actually a secret, but it can flag suspicious patterns.

Is the data sent to a server?

No. The validation runs entirely in your browser using a YAML parser plus schema-checking logic, all in JavaScript. Your compose file — which often contains internal infrastructure details, environment variable names, and other config you wouldn't want exposed — never leaves your machine. That's the right answer for production configurations.

Docker Compose Validator

Validate Docker Compose YAML files online instantly. Free docker-compose.yml validator with syntax checking, structure validation, and helpful error messages.

Developer Tools

Instant results

Docker Compose YAML

About Docker Compose Validator

Validate your Docker Compose YAML files for syntax errors and structural issues. This tool checks YAML syntax, Compose version compatibility, service structure, port and volume formats, dependency references, cycle detection in depends_on, and common misconfigurations. All validation runs entirely in your browser.

How to Use Docker Compose Validator

Paste docker-compose.yml

Drag the file into the drop zone or paste the contents directly. The tool parses the YAML and runs it through the Compose schema. You don't need a Docker daemon installed — everything happens in the browser, which means your file (and any sensitive config it contains) stays on your machine.

Specify version (optional)

If your file has a 'version:' line, the tool uses that to pick the right schema for validation. If you've omitted it (which is increasingly common with newer Compose versions where it's optional), specify the target version manually. Different versions support different features, so picking the right one matters for accurate validation.

Review validation output

The tool reports a pass-or-fail result, with specific error messages tied to line numbers when something's wrong. Beyond hard errors, you'll often see warnings about deprecated features, risky patterns (inline secrets, missing healthchecks), or options that work but aren't recommended in your version. Read both — the warnings catch real issues even when the file is technically valid.

Fix and re-validate

Address each error in your editor and run validation again. Iterate until the file is clean. Once it is, plug the validator into your CI pipeline so every commit gets the same check automatically — that's how you stop config errors from sneaking into the repository between manual validation runs.

When to Use Docker Compose Validator

Catch syntax errors before they hit production

Compose YAML is easy to mistype — wrong indentation, a missing colon, a key name that's almost-but-not-quite right. The validator parses your file and surfaces structural issues before 'docker compose up' fails with a cryptic error. Especially useful in CI/CD pipelines and pre-commit hooks where catching the problem at the moment of authorship is dramatically cheaper than discovering it during deployment.

Multi-service validation

A compose file with ten or more services has a lot of moving parts — service references in depends_on, named networks linking containers, volumes being mounted in multiple places. The validator checks that the references resolve, that networks and volumes referenced are actually defined, and that depends_on relationships make sense. It saves real debugging time on the kinds of bugs that only manifest at runtime.

Schema validation

Compose has a formal schema that has evolved across versions 1, 2.x, and 3.x, with subtle differences in which keys and options are valid where. The validator checks your file against the schema for the version you're using, catching deprecated features, options that don't exist in your version, and required fields that are missing. Particularly helpful when modernizing legacy compose files or migrating between versions.

CI/CD integration

Adding a validation step to your pipeline catches issues before they make it to deployment. GitHub Actions, GitLab CI, Jenkins — all of them can run a compose validator as a quick pre-deployment check, which gives developers fast feedback when they break something and stops invalid configurations from reaching production where the failure modes are louder.

Docker Compose Validator Examples

Valid file

Input

version: '3.8'\nservices:\n  web:\n    image: nginx

Output

Valid. Version 3.8 detected. One service (web) found. All required fields present.

A minimal but complete compose file. The validator confirms the version syntax is correct, the service definition is structurally valid, and the required fields (specifically, 'image' or 'build') are present. This is the bare-bones starting point that most real compose files build out from.

Invalid - missing image/build

Input

version: '3.8'\nservices:\n  web:\n    ports:\n      - 80:80

Output

Error: Service 'web' has neither 'image' nor 'build'. One of these is required.

Every service needs either 'image' (to pull an existing image from a registry) or 'build' (to build from a Dockerfile in your repo). Forgetting both is a common mistake when you're sketching out a new service and haven't decided yet whether to build or pull. The validator catches it before runtime.

Invalid - bad reference

Input

version: '3.8'\nservices:\n  web:\n    image: nginx\n    depends_on:\n      - db

Output

Error: Service 'web' depends on 'db' but 'db' is not defined in this file.

The web service declares a dependency on a 'db' service that doesn't exist in this compose file. This kind of dangling reference happens constantly when you refactor, rename services, or copy-paste config from examples without bringing all the related pieces. Catching it statically is much nicer than seeing it explode when you try to start the stack.

Tips & Best Practices for Docker Compose Validator

1.Validate on every commit. A pre-commit hook or a CI step that fails the build on validation errors catches issues at the moment they're introduced, when fixing them is cheap. Letting bad config reach a feature branch where someone else discovers it during their own work is much more expensive.
2.Match the schema version to the features you actually use. The 3.x schema unlocks Swarm-specific 'deploy' keys but drops some 2.x features. Using a version mismatch (declaring 3.x while using 2.x-only options) produces obscure errors that the validator can flag for you.
3.Keep individual compose files small. Splitting into multiple files — docker-compose.yml as the base, docker-compose.override.yml for local development, docker-compose.prod.yml for production overrides — is much easier to validate and maintain than one sprawling file with everything mixed together.
4.Use environment files for secrets and per-environment configuration rather than hardcoding values in the compose file itself. Better validators flag inline secrets as a warning, since checking compose files into git is normal but checking secrets into git is a security incident waiting to happen.
5.Pair validation with the official Compose specification docs. The validator catches structural issues; the docs explain what each key actually means semantically. You need both — passing validation doesn't mean your config does what you think it does.
6.Service names need to be DNS-compatible because Docker uses them as hostnames on the internal network. That means lowercase letters, digits, and hyphens — no underscores, no spaces, no uppercase. The validator catches invalid characters before they cause runtime networking issues.

Frequently Asked Questions

It runs through a few layers. First, YAML syntax — correct indentation, balanced quotes, valid structure. Second, Compose schema compliance — the version you declared is valid, every field is supported in that version, and required fields are present. Third, references — depends_on points at services that actually exist, named networks and volumes are declared somewhere. Fourth, value formats — port ranges are sensible, paths are valid, environment values parse correctly.

Docker Compose Validator

About Docker Compose Validator

How to Use Docker Compose Validator

Paste docker-compose.yml

Specify version (optional)

Review validation output

Fix and re-validate

When to Use Docker Compose Validator

Catch syntax errors before they hit production

Multi-service validation

Schema validation

CI/CD integration

Docker Compose Validator Examples

Valid file

Invalid - missing image/build

Invalid - bad reference

Tips & Best Practices for Docker Compose Validator

Frequently Asked Questions

Related Tools

Regex Validator

Regex Tester

MIME Type Lookup

HTTP Status Code Reference

.env File Validator

Git Command Generator