package.json Generator

What this generator does

Builds a manifest as data, serialises it as formatted JSON, parses that text back and compares it with the original. It then checks npm's rules: the package name against npm's name grammar, the version against semver, every dependency range against the caret, tilde and exact forms, and every script against being empty.

How to use this tool

1. Generate a manifest.
2. Read the scripts and dependency ranges.
3. Check the verification note under the file.
4. Copy it as a starting point, or as a fixture for something that reads manifests.

Understanding the controls

Generate

Draws a fresh package name, version, licence and set of dependencies. The scripts block stays consistent because those four commands are what nearly every project needs.

Worked examples

A generated manifest

"version": "2.11.3" — three real numbers assembled and validated against the semver grammar, and dependencies like "zod": "^3.24.1" using the caret range npm writes by default, letting minor and patch updates through but not a major version bump.

Common use cases

• Starting a small project without copying a manifest from another one
• Producing fixtures for a tool that parses package.json files
• Showing what a caret range looks like in a dependencies block
• Teaching the difference between dependencies and devDependencies
• Getting a scripts block with the four commands most projects need

How this generator works

The version is assembled from three numbers rather than a template, so it is a real semantic version rather than a plausible-looking string, and it is tested against the semver grammar afterwards. Dependency ranges use the caret form npm writes by default. The manifest is marked private, which is npm's own guard against publishing something by accident — a sample manifest is exactly the kind of file that ends up in a real project.

Randomness and fairness

Name, version numbers, licence and the choice of dependencies are drawn with the browser's cryptographic random source, so running it again gives a genuinely different manifest.

For how randomness is produced across the whole site, see how Generate Random works.

Limitations and good to know

• Scoped names like @org/package are not generated, though npm accepts them.
• The dependency list is a small built-in set of well-known packages rather than a live search of npm, and the versions are examples rather than the current ones.
• Fields a published package needs — repository, author, files, exports — are not included, because this is a starting point rather than a release manifest.
• The check confirms the manifest is well-formed, not that the dependencies resolve or that the versions still exist.

Privacy and your data

The manifest is generated in your browser from built-in values. You enter nothing, nothing is uploaded or stored, and analytics records only that the tool ran.

Frequently asked questions

Why is the manifest marked "private": true?

It's npm's own safeguard against accidentally publishing a package — running npm publish on a manifest with this flag set fails outright. A generated sample manifest is exactly the kind of file that can end up committed to a real project, so this default protects against publishing it by mistake.

What's the difference between the caret range and an exact version?

A caret range like ^3.24.1 allows npm to install any version that doesn't change the leftmost non-zero digit — so 3.25.0 is allowed but 4.0.0 is not — which is how most projects want their dependencies to update automatically. An exact version like 3.24.1 with no prefix locks to that one version precisely, with no automatic updates at all.