Check the license field of a package.json against the SPDX list, as npm does
Runs in your browser. Nothing you type is sent anywhere. Checked against sources on 16 Oct 2026.npm prints "license should be a valid SPDX license expression" when the license field is not exactly an SPDX identifier such as MIT or Apache-2.0, a combination such as (MIT OR Apache-2.0), UNLICENSED, or SEE LICENSE IN followed by a file name. The check here uses the same rules and the same list of 734 identifiers, and suggests the right spelling for near misses such as "Apache 2.0".
Paste or type your input.
Choose the options you need.
Press Ctrl+Enter, then copy or download.
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.
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 |
The rest of the article, and all 6 questions about package.json Validator, are on the package.json Validator page.
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.
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.
On the related tools: Readability Checker – Flesch reading ease and grade level, with what to change · JSONPath Evaluator – Evaluate a JSONPath expression and get the matching values and their paths.