Bundlejs

Online JavaScript bundling and size analysis, honestly reviewed. No marketing fluff, just what you actually get.

TL;DR

• What it is: A free, browser-based tool that bundles, minifies, and reports the gzip/brotli size of npm packages — all running locally inside your browser tab, no server involved [1].
• Who it’s for: JavaScript and TypeScript developers who need a quick bundle size sanity check before shipping a dependency, without installing Node or running a local build [1][4].
• Cost: Free. No plans, no seats, no usage limits. The only cost is the compute in your browser tab [1].
• Key strength: Runs entirely client-side via esbuild-wasm — your code never leaves the browser. Supports treeshaking, multiple CDN sources, TypeScript, JSX, shareable links, and a REST API for badge generation [1].
• Key weakness: 904 GitHub stars is a modest signal for a tool asking you to rely on it in CI pipelines. High memory usage from the esbuild-wasm + Monaco combo, uneven support for edge-case packages, and no hover intellisense are real rough edges [1].

---

What is Bundlejs

Bundlejs (pronounced “bundle js”) is an online tool for checking the minified, compressed size of npm packages. You type in a package name — or paste code importing multiple packages — and it tells you exactly how many kilobytes your production bundle will be after gzip or brotli compression. The entire bundling operation runs inside your browser via esbuild-wasm; no files are uploaded to any server [1].

The project was built by Okiki Ojo and lives at https://bundlejs.com. It positions itself as a more accurate alternative to bundlephobia, the older tool most developers know. The core difference: bundlephobia runs bundling on a backend server and returns a cached result. Bundlejs runs bundling locally, which means it can treeshake imports, bundle multiple packages together, show you the resulting code, and give you a visual treemap of what’s eating your bundle weight [1].

Under the hood the tech stack is: monaco-editor for the code editor, esbuild-wasm for bundling and treeshaking, WebAssembly ports of gzip (denoflate), brotli (deno_brotli), and lz4 (deno_lz4) for compression, esbuild-visualizer for the treemap view, and Umami for cookie-free analytics [1]. The four custom esbuild plugins — HTTP, CDN, EXTERNALS, and ALIAS — are what make it possible to resolve npm package imports in a browser context where there’s no file system or npm install [1].

As of this review, the GitHub repository sits at 904 stars. That’s honest: bundlejs is a useful niche tool with a small but real following, not a breakout project.

---

Why people choose it over bundlephobia and local builds

The third-party coverage of bundlejs is thin — sources [2], [3], and [4] are general articles about JavaScript bundlers and esbuild rather than direct reviews of bundlejs. What we have is the author’s own documentation [1] and the tool’s behavior. So this section is honest about that gap.

Versus bundlephobia. Bundlephobia is the incumbent every developer knows. The key limitation reviewers repeatedly surface for bundlephobia is that it bundles on their servers against a fixed configuration — you can’t treeshake specific exports, bundle multiple packages together, or verify the output code. Bundlejs closes exactly those gaps: you can import { specific method } from a package, bundle it with three other packages, and see the exact output code in the Monaco editor alongside the compressed size [1]. This matters when you’re trying to understand whether a named import is actually being treeshaken or whether the full library is getting dragged in.

Versus running esbuild locally. The no-install angle is real. For a quick “how big is this if I add it” check during code review or dependency evaluation, opening a browser tab is faster than npm install esbuild && npx esbuild .... The offline support (modules cached from previous visits) reinforces this [1]. For anything more complex — builds with custom plugins, output format tuning, production CI pipelines — you’d use esbuild directly.

The REST API angle. Bundlejs added a REST API at https://deno.bundlejs.com that serves bundle size badges. The use case is README files: drop a badge into your open-source project’s README and it auto-displays the current gzip size of your package [1]. This is a concrete workflow hook that makes bundlejs sticky for open-source maintainers who want to signal bundle-consciousness to users.

On the “local runs in browser” privacy angle. For internal packages, proprietary code, or source you’d rather not ship to a third-party server, the browser-local execution matters. Nothing is transmitted [1]. This is a minor selling point — most people won’t care — but it’s genuinely true.

---

Features

Based on source [1] and the README:

Core bundling:

• Bundle any npm package by name, with optional treeshaking of specific exports [1]
• TypeScript, JavaScript, JSX support via esbuild-wasm [1]
• CommonJS and ESM modules both supported [1]
• Minification built in [1]
• Output code visible in Monaco editor — you can see exactly what got bundled [1]

Compression reporting:

• Gzip, brotli, and lz4 compressed sizes reported [1]
• Human-readable bytes formatting [1]
• Side-by-side comparison of compression formats [1]

Bundle analysis:

• Visual treemap via esbuild-visualizer — see which modules are taking up the most space [1]
• Useful for diagnosing why a bundle is larger than expected [1]

URL queries and sharing:

• Shareable links via URL query parameters: ?q=react,react-dom&treeshake=[*],[*] [1]
• Share button compresses current editor code into a URL string [1]
• Reproducible bundles without accounts or saved workspaces [1]

CDN sources:

• Resolves npm package imports via CDNs (unpkg, skypack, esm.sh, etc.) [1]
• Supports deno modules, npm packages, and arbitrary HTTPS scripts [1]
• HTTP caching means previously-fetched modules work offline [1]

REST API:

• Badge generation: replace bundlejs.com with deno.bundlejs.com and add /?badge to get a README badge [1]
• API at https://deno.bundlejs.com and https://edge.bundlejs.com [1]

Known rough edges from source [1]:

• High memory usage from the esbuild-wasm + Monaco combination — noticeable on older machines or many simultaneous browser tabs
• Some edge-case packages fail to bundle (the README calls out monaco-editor specifically)
• No autocomplete or hover intellisense in the editor
• Mobile support is limited

---

Pricing: Free, With No Catch

There is nothing to price here. Bundlejs is free to use on the website, the source is MIT-licensed on GitHub, and the REST API (badge generation) appears to be free as well [1]. No tiers, no seats, no usage limits documented anywhere.

Comparison to the alternatives:

Tool	Cost	Server-side?	Treeshake?
Bundlejs	Free	No (browser)	Yes
Bundlephobia	Free	Yes (their servers)	No
pkg-size.dev	Free	Partial	Yes
Local esbuild	Free	Local (your machine)	Yes

The cost consideration isn’t “SaaS vs self-hosted savings” — it’s “do I want to set up esbuild locally for every project just to check a dependency size?” For one-off checks, bundlejs wins on convenience. For CI integration with production build pipelines, local esbuild wins on control.

---

Deployment Reality Check

Bundlejs has no server deployment in the traditional sense. The tool runs in your browser. If you want to self-host the application itself, the source is at https://github.com/okikio/bundle under MIT license — but there’s no documented Docker setup, no Helm chart, and no deployment guide for self-hosting the web application [1]. This is a web app you’d clone and serve as static files, not infrastructure you’d provision.

The REST API at https://deno.bundlejs.com is a Deno Deploy function. If you wanted to self-host that, you’d be running a Deno application. Again, no explicit self-hosting documentation exists for this path.

What “self-hosted” means here: bundlejs runs entirely in your browser tab. In that sense it’s the most self-hosted tool imaginable — there’s no vendor dependency for the bundling computation itself. The dependency is on the bundlejs.com domain being up to serve the initial application and the CDN endpoints being reachable for package fetching.

For teams wanting to embed this: the REST API endpoint is the integration path. You can hit https://deno.bundlejs.com/?q=your-package&badge=detailed from a CI step or a README to surface bundle size without any local setup.

---

Pros and Cons

Pros

• Zero setup. Open a tab, type a package name, get a result. No npm install, no build config, no Node version management [1].
• Client-side execution. Bundling runs in your browser — nothing leaves your machine. Matters for proprietary packages or internal code you don’t want on a third-party server [1].
• Treeshaking support. Unlike bundlephobia, you can specify named exports and see only what you actually import in the bundle size number. This produces more accurate estimates [1].
• Visible output code. The Monaco editor shows you the resulting bundle. You can verify that treeshaking worked, catch accidental CJS polyfill includes, spot dynamic imports that didn’t shake out [1].
• Visual treemap. esbuild-visualizer integration means you can see which modules are contributing most to bundle weight — useful for diagnosing unexpectedly large bundles [1].
• REST API + badge generation. A concrete integration hook for open-source README authors [1].
• MIT license. If you want to fork or embed this in internal tooling, you can [1].
• Offline capable. Previously-fetched modules are cached — works without a live CDN connection for repeat checks [1].

Cons

• High memory usage. The README explicitly acknowledges this as a known issue with the esbuild-wasm + Monaco combination [1]. Expect a heavy browser tab, especially on complex bundles.
• Edge-case package failures. Some packages fail to resolve or bundle correctly. The README cites monaco-editor as an example [1]. You’ll occasionally hit a wall with complex packages.
• No hover intellisense. The Monaco editor doesn’t provide type information or import completions. It’s closer to a plain editor than a full IDE experience [1].
• Limited mobile support. Not a realistic mobile workflow tool [1].
• 904 stars. Not a large community signal. The project appears to be primarily maintained by one person. Bus factor is real for a dependency-evaluation tool you’d integrate into a workflow.
• No self-hosting documentation. If bundlejs.com goes down and you need the tool, there’s no documented path to spin up your own instance quickly [1].
• Narrow use case. This is a bundle size checker, not a general-purpose bundler or build tool. Sources [2], [3], [4] cover esbuild and bundling concepts broadly — bundlejs doesn’t replace any of that; it’s one narrow utility at the top of that stack.

---

Who Should Use This / Who Shouldn’t

Use bundlejs if:

• You’re a JavaScript or TypeScript developer evaluating whether to add an npm dependency and want a quick bundle size check before you commit.
• You’re an open-source maintainer who wants a bundle size badge in your README to signal you care about keeping the library lean.
• You want to verify that your named imports are actually being treeshaken in practice, not just in theory.
• You’re comparing two packages that do the same thing and want an apples-to-apples compressed size comparison.
• You’re reviewing a PR and want to quickly check what a new dependency will cost in bytes.

Skip it if:

• You’re a non-technical founder. This tool is for engineers evaluating JavaScript bundle composition. It has no business application outside of frontend development workflows.
• You need a production CI bundle size tracker. Use tools like bundlesize, size-limit, or bundlemon with proper CI integration and historical tracking instead.
• You need to understand why your application’s bundle is large. Bundlejs evaluates individual packages in isolation, not your full build graph. Use your build tool’s analyzer (webpack-bundle-analyzer, Rollup’s visualizer, Vite’s rollup-plugin-visualizer) for that.
• You need reliable, auditable results at scale. The 904-star count and single-maintainer structure means you should treat this as a convenience tool, not a compliance-grade dependency.

---

Alternatives Worth Considering

• Bundlephobia (https://bundlephobia.com) — The incumbent. Simpler, server-side, no treeshaking support, but faster for a one-shot “how big is this package” query. More reliable infrastructure than a 904-star project.
• pkg-size.dev — Similar browser-local approach with a slightly different UI. Worth a comparison if bundlejs fails on a particular package.
• esbuild (local) — If you’re doing this more than occasionally, just install esbuild directly. npx esbuild --bundle --minify --analyze gives you everything bundlejs does in a scriptable CLI form [2][4].
• size-limit — For tracking bundle size over time in CI with budget thresholds. Not a one-shot checker but the right tool if you want this automated on every PR.
• Rollup REPL / Vite Playground — For framework-specific bundle analysis where esbuild-wasm might not reflect your actual build output.

---

Bottom Line

Bundlejs is a genuinely useful, well-built developer utility for a narrow job: quickly checking what an npm dependency actually costs in compressed bytes, without installing anything. The browser-local execution, treeshaking support, and code output visibility make it meaningfully better than bundlephobia for the cases where you need more than a cached number. The REST API and badge generation add a concrete integration hook for open-source maintainers. The honest caveats are also real: high memory usage, edge-case package failures, no intellisense, a small community, and no documentation for self-hosting if bundlejs.com ever disappears. Use it as a convenience tool in your developer workflow — not as production infrastructure. If you find yourself hitting bundlejs.com more than a few times a week, that’s a signal to invest twenty minutes setting up size-limit in your CI pipeline instead.

---

Sources

1. Okiki Ojo — “bundlejs: An online esbuild based bundler & npm bundle size checker” (blog.okikio.dev). https://blog.okikio.dev/documenting-an-online-bundler-bundlejs
2. Maneshwar, DEV Community — “Setting Up a Basic JavaScript Bundler with Esbuild” (dev.to). https://dev.to/lovestaco/setting-up-a-basic-javascript-bundler-with-esbuild-3jif
3. Léa Tortay — “Practical guide to bundlers” (lea-tortay.com). https://lea-tortay.com/articles/practical-guide-to-bundler/
4. Snipcart — “JavaScript Bundlers: In-Depth Guide” (snipcart.com). https://snipcart.com/blog/javascript-module-bundler

Primary sources:

• GitHub repository: https://github.com/okikio/bundle (904 stars, MIT license)
• Official website: https://bundlejs.com
• REST API: https://deno.bundlejs.com