Paste the full contents of your composer.json file
// QUICK LOAD
Validation results appear here
Paste your composer.json and click Validate// validate composer.json syntax and structure instantly
Validate your composer.json file instantly in the browser. Checks JSON syntax, required fields, version constraints, license, and autoload configuration for free.
Validation results appear here
Paste your composer.json and click ValidateCopy the full contents of your composer.json file into the input area on the left.
Hit the Validate button or press Ctrl+Enter to run all checks instantly.
Errors, warnings, and notices are listed with field names and fix suggestions.
Composer JSON Validator checks your composer.json file for syntax errors, missing required fields, and common configuration mistakes. It runs entirely in your browser — no files are sent to any server.
Whether you're publishing to Packagist or setting up a new PHP project, this tool helps you catch issues before they break your build or CI pipeline.
No. All validation runs entirely in your browser using JavaScript. Your code never leaves your machine — there is no server processing involved.
The name field must follow the format vendor/package using lowercase letters, numbers, hyphens, underscores, or dots. Example: myvendor/my-package.
Composer supports several formats: exact (1.0.2), range (>=1.0 <2.0), wildcard (1.0.*), tilde (~1.2), and caret (^1.2.3). The caret operator is recommended for most packages.
PSR-4 namespace keys must always end with a double backslash (\\). For example: "App\\": "src/". Missing the trailing backslash will cause autoloading to fail.
Setting minimum-stability to dev lets you install development packages, but it can pull in unstable dependencies. Use it with "prefer-stable": true to minimize risk.
This tool validates the most important fields including name, description, require, license, autoload, authors, type, and minimum-stability. For the full spec, refer to the official Composer schema.
A Composer JSON Validator is a tool that checks the structure and contents of your composer.json file — the core configuration file for PHP projects that use Composer, the most widely used PHP dependency manager. A valid composer.json ensures Composer can correctly read your project's metadata, resolve dependencies, configure autoloading, and publish the package to Packagist if needed.
Even experienced PHP developers make subtle mistakes in composer.json: a missing trailing backslash in a PSR-4 namespace, a wildcard version constraint that pulls in breaking changes, or a missing license field that gets flagged by Packagist reviewers. This validator catches these issues instantly, before they cause a build failure or a failed publish attempt.
The composer.json file is a JSON document that Composer reads to understand your project. It includes fields like:
vendor/package format. Required for packages published to Packagist.symfony/console or guzzlehttp/guzzle, along with their version ranges.Even with good intentions, many developers ship composer.json files with subtle problems. Here are the most frequent issues this validator catches:
vendor/package pattern. Uppercase letters, spaces, or missing slashes all cause errors.\\. Forgetting this breaks autoloading silently, causing class-not-found errors at runtime."vendor/package": "*" means Composer will install any version, including breaking major releases. Always use specific constraints like ^2.0 or ~1.5."php": "^8.1" entry in require, your package could be installed on unsupported PHP versions, leading to cryptic runtime errors.PSR-4 (PHP Standard Recommendation 4) is a standard for autoloading PHP classes from the filesystem. It maps namespace prefixes to directory paths. For example:
"autoload": {
"psr-4": {
"App\\": "src/"
}
}This tells Composer that any class in the App\ namespace can be found in the src/ directory. The class App\Http\Controller would map to src/Http/Controller.php. The trailing double backslash in the namespace key is mandatory — without it, Composer cannot resolve the mapping correctly.
Composer's version constraint system is one of its most powerful features, but also one of the easiest to misconfigure. The main formats are:
1.2.3 — installs only that exact version. Rarely useful in practice.1.2.* — installs any patch version within the 1.2.x series.~1.2.3 — allows patch-level updates within the 1.2.x series.^1.2.3 — allows minor and patch updates within the 1.x series (the most common and recommended format).>=1.2 <2.0 — explicit lower and upper bounds.For libraries, the caret operator (^) is almost always the right choice because it follows semantic versioning: breaking changes only happen in major version bumps, and the caret ensures you get bug fixes and new features while staying protected from breaking changes.
Packagist, the default Composer package repository, performs its own validation when you submit or update a package. If your composer.json fails validation, the package update will be rejected, and your users may be left on an outdated version. Catching these issues locally — before pushing a tag to GitHub or GitLab — saves you time and protects your users from disruption.
Additionally, many CI/CD pipelines run composer validate as an early step. If your composer.json has issues, the entire build fails. Using this tool as a quick pre-commit sanity check can prevent unnecessary CI failures.
This validator reports three levels of issues to help you prioritize fixes:
name format, PSR-4 namespace without trailing backslash.description, wildcard version constraints, deprecated PSR-0 autoloading.A clean validation result — no errors, no warnings — is the baseline you should aim for before publishing any PHP package. This Composer JSON Validator helps you get there in seconds, entirely in your browser, for free.