Check a package.json the way npm reads it: name, version, license, dependencies and syntax
Runs in your browser. Nothing you type is sent anywhere. Checked against sources on 16 Oct 2026.A package.json validator checks the file npm reads before it installs or publishes a package. Paste the file to see JSON syntax errors with their line, the exact warnings npm prints, whether the name is allowed, whether the license is one of 734 SPDX identifiers, and dependency versions that are not real ranges.
Paste the package.json, open the file, or click Try an example.
Fix any JSON syntax error first: its line and column are shown, with the usual cause.
Read what npm says: the warnings and errors npm itself prints for this file, word for word.
Work through the further checks, such as unpinned dependencies, and click Copy report to share them.
npm reads package.json strictly in some places and loosely in others: a bad version stops everything, while a missing description only earns a warning. This page checks the file in three layers and shows each separately.
1. JSON syntax. The first mistake is shown with its line and column and the usual cause: a trailing comma, a comment, single quotes or an unquoted key. Duplicate keys are listed too, because JSON.parse quietly keeps only the last one and the first value is lost.
2. What npm says. The warnings and errors npm itself prints for this file, word for word, such as "No repository field." or "Invalid version". They come from rewriting npm's own normalize-package-data, validate-npm-package-name and validate-npm-package-license, and the tests compare the answers with those packages on 80 sample files, 44 names and 54 license strings.
| npm message | What to do |
|---|---|
| Invalid version: "1.0" | Write three numbers, such as 1.0.0 |
| No license field. | Add "license": "MIT" or another SPDX id |
| license should be a valid SPDX license expression | Use the exact id, such as Apache-2.0 |
| scripts['server'] should probably be scripts['start']. | Rename the script to start |
| name can no longer contain capital letters | Use lower case for a new package |
3. Further checks. Dependencies written as *, latest or an empty string; version ranges that are not valid, checked with the same rules as npm; a package listed in both dependencies and devDependencies; git dependencies without a tag; local paths in a published package; a "type" other than module or commonjs; engines ranges; and the placeholder test script npm init leaves behind.
A file marked "private": true is never published, so npm stays quiet about its warnings; the page says so. Everything runs in your browser; nothing you paste is sent anywhere.
The license field must be an exact SPDX identifier, such as MIT, ISC or Apache-2.0, or a combination like (MIT OR Apache-2.0). Near misses such as "mit", "Apache 2.0" or "BSD" fail. For closed-source code write UNLICENSED, or SEE LICENSE IN LICENSE.txt to point at your own file.
Not for a new package. Names must be lower case, at most 214 characters, URL-safe, must not start with a dot or underscore, and must not be a Node.js core module such as http. Some old packages have capitals because the rules came later, and npm still installs them, but it refuses a new one.
The version must be a full semantic version with three numbers, such as 1.0.0 or 2.1.0-beta.1. Writing 1.0, latest or an empty string stops npm from reading the package at all. npm accepts a leading v and tidies it away, so v1.2.3 is read as 1.2.3.
Usually, yes. Both accept any version, so two installs a month apart can get different major versions with breaking changes. Write a caret range such as ^4.17.21, which takes fixes and features but stops before the next major version, and commit the lock file so every install matches.
No. package.json is strict JSON, which has no comments, so a // or /* line stops npm from reading the file. A common workaround is a key named "//" with a string value; npm ignores keys it does not know. The syntax check here points at the line of the comment.
npm warns when package.json has no repository, because the npm website links to the source code from it. Add "repository": {"type": "git", "url": "git+https://github.com/user/repo.git"}. The warning does not stop anything, and npm skips it entirely for a package marked "private": true.
Rates and rules change; check the source before you rely on a figure.
Still stuck? Ask about package.json Validator and anybody who knows can answer. No account needed.
Same job, other tools: Twitter Card Validator – Check twitter:card tags and the og: tags X falls back to · HTTP 403 Forbidden – The difference between 403 and 401, and when a 404 is the safer reply · HTTP 404 Not Found – What a 404 means, when to send it, and when 410 or 403 is the better answer.
On the related tools: Readability Checker – Flesch reading ease and grade level, with what to change.