Skip to content
100% local

package.json dependency overview

Split a package.json into production, dev, peer and optional dependencies with their version ranges.

Input
Output

package.json dependency overview

Paste the contents of a package.json file and this tool sorts every dependency into its group — production, development, peer and optional — and lists the version range next to each package name. It is built for opening an unfamiliar repository and seeing what it depends on without scrolling a wall of JSON, or for reviewing a pull request that touches the dependency list.

Choose how the list is ordered: grouped by type or flattened alphabetically. Group counts show how many packages sit in each bucket at a glance. "Explain version ranges" adds a short note to every line describing what its range allows — caret permits minor and patch updates, tilde only patch updates, an exact version never updates on its own, and a bare asterisk accepts anything. Two more checkboxes surface risk: one flags packages pinned to an exact version or left fully unconstrained, the other flags any package name repeated across groups, usually a sign the entry needs cleaning up. A separate toggle appends the engines and packageManager fields, when present.

Output renders as a plain aligned table, a grouped plain-text list, or a Markdown table ready to paste into a README or a pull-request description. The tool only reads the fields it needs and ignores the rest, so pasting a full package.json with scripts and metadata works exactly like pasting a trimmed-down version.

Everything runs locally in your browser. Your package.json is never uploaded, which matters if it names private or unpublished packages. Copy the result, download it as a .txt file, or send it straight to another tool's input to keep working on it.

FAQ

Which fields does it read from package.json?
dependencies, devDependencies, peerDependencies, optionalDependencies, and — when the option is on — engines and packageManager. Every other field, including scripts and metadata, is ignored.
What counts as a "pinned" or "wildcard" version?
A pinned version has no range operator at all, like "4.17.21" — it never updates on install. A wildcard is "*" or an empty string, which accepts any version. The flag option marks both, since they sit at opposite extremes of the same problem: no control over what gets installed.
Why would a package show up in more than one group?
It usually means a dependency was added twice by hand, or moved from devDependencies to peerDependencies without removing the old entry. The duplicate flag calls out any package name that appears in two or more of the four groups.
Does it validate the version ranges against npm’s registry?
No. It only reads the range syntax already in the file — it does not check the network for what versions actually exist, so it works fully offline.
Is my package.json uploaded anywhere?
No. Parsing and formatting run entirely in your browser — your file, including any private package names it contains, never leaves your device.