Loading page
About this tool
Build a valid package.json with metadata, scripts, module type, exports, engines and license — validated against npm's naming and semver rules.
This generator builds a complete package.json validated against npm's real rules: names must be lowercase, URL-safe and at most 214 characters including the scope, and versions must satisfy Semantic Versioning 2.0.0. It assembles metadata, scripts, the "type" field, an exports map, engines and license for developers starting a new Node.js package or tidying an existing manifest — and warns about traps like UNLICENSED public packages and how caret ranges behave on 0.x versions.
Open Package JSON Generator on AltFTool — it loads instantly in your browser.
Paste or upload your source content.
Choose the target format or conversion mode.
Copy or download the converted result.
Name and version are checked with the same rules npm itself enforces, not a loose guess.
Emits type, an exports map and optional sideEffects: false for bundler tree-shaking.
Flags UNLICENSED without private, 0.x caret behaviour, and the deep-import lockout that exports causes.
It must be lowercase, contain only URL-safe characters (letters, digits, hyphens, dots, underscores and tildes), not start with a dot or underscore, and be at most 214 characters including a scope like @org/. Uppercase names were allowed historically but new packages cannot use them.
It makes Node.js treat every .js file in the package as an ES module, so import/export work natively and require() is unavailable in those files. Without it the default is commonjs; .mjs and .cjs extensions override the setting either way.
main names a single entry file and leaves the whole package open to deep imports; exports is the modern replacement that takes precedence in Node 12.7+ and explicitly maps every importable path. Once you add exports, undeclared subpaths like pkg/lib/util can no longer be imported — declare each one you want public.
Only sometimes. npm treats engines as a warning unless the user sets engine-strict=true, while pnpm and Yarn enforce it by default and fail the install. It is still worth declaring, both as documentation and for the managers that respect it.