What is actually in your package.json? Check before you ship
Your `package.json` is about to land in npm. Or in CI. Or get pasted into a monorepo nobody has cleaned up in two years. The question: is this file actually OK? Is the name valid, the version proper SemVer, do you have the same package in both `dependencies` and `devDependencies`, will `"react": "*"` blow up the next time someone runs npm install.
You paste the whole file into the textarea. The validator does four things:
- checks whether it is valid JSON at all (most common bug: a trailing comma after the last field);
- validates the npm schema: name matches registry rules, version is proper SemVer, root is an object;
- draws a graph of your scripts: which script calls which (e.g. `build` calls `clean` and `compile`), so you can immediately see what happens when you run `npm run release`;
- audits dependencies: duplicates between deps and devDeps, wildcards (`"*"`, `"latest"`), mixed styles (`^` vs `~` vs exact pins), missing peers.
Everything runs locally in your browser. Nothing leaves the page, so you can safely paste your company's `package.json`, no one outside your computer sees the dependency names, private registry paths, or script names.
How to use it
- Paste the whole `package.json` into the big textarea at the top. If you just want to see how this works, click Load sample, the validator will load an example package with one intentionally left issue.
- The "Validity" card shows the result green or red right away. Green = the JSON parses and the npm schema is satisfied. Red = click through the error list to see the exact things to fix.
- The "Metadata" card shows the name, version, module type (ESM or CommonJS), license, repository in a readable layout instead of you scanning through raw JSON.
- The "Scripts" card draws the graph: which script calls which. You see `build` → `clean` + `compile` → `tsc`. Priceless on an inherited project with 30 scripts.
- The "Dependencies" card counts packages across four sections (deps / devDeps / peerDeps / optional) and lists detected issues: duplicates, wildcards, missing peers, mixed version styles.
- The "Required fields" card is a green or amber checklist: name, version, description, license, scripts, repository. You know immediately what is missing before this package can be published to npm.
- Click Format if you pasted a single-line `package.json` and want a readable output to copy back.
When this is useful
Five situations where the validator saves you an hour of CI debugging:
- Before your first `npm publish`. A package is going to npm for the first time. The validator checks whether the name is valid (bad characters = registry rejects), whether the version is SemVer, and whether you have a license. Without it you find out only after `npm publish` when the publish fails.
- Code review on a monorepo pull request. Someone added a package. You paste its `package.json` into the validator and instantly see **`"react": "*"` in deps**. You comment on the PR before merging something that will break on the next update.
- Audit of a project you are about to inherit. You take over a legacy project where 47 scripts call each other. The validator draws the graph, you see that `release` calls `build`, which calls `compile`, which calls `tsc`. A road map instead of reading 47 lines top to bottom.
- Figuring out why CI fails on `npm ci`. The CI build will not pass. You paste `package.json` and see: `package-x` is in both deps and devDeps, the lock-file gets confused, `npm ci` picks different versions. The validator surfaces this as a red issue.
- Migrating from npm to pnpm or yarn. Before the migration you paste both `package.json` files (old and new) and check whether peer dependencies are consistent, whether wildcards are gone (pnpm is less forgiving), and whether scripts form a sensible graph.
Questions and answers
No. All validation runs in your browser. The file never leaves your computer, there is no API on the other side. You can safely paste a company `package.json` with private package names, internal registry paths, or script names like `deploy-staging`. The validator works 100% offline after the page first loads, you can even disconnect from the internet and it will still work.