Cloudflare Worker Too Large: Check the 64 MiB Bundle Limit
If Cloudflare rejects a Worker because its script is too large, check the uncompressed bundle size first. The current Worker size limit is 64 MiB on both Free and Paid plans. In Wrangler output, Total Upload is the number to compare with that limit; the adjacent gzip value is informational.
Cloudflare removed the former 3 MB Free and 10 MB Paid compressed-size limits on September 4, 2026. Advice based on those old thresholds can therefore send you toward the wrong fix.
Measure the upload before deploying
Run a dry deployment and keep the generated bundle plus its esbuild metadata:
pnpm dlx wrangler@latest deploy \ --dry-run \ --outdir .wrangler-bundle \ --metafileOn a minimal Worker tested with Wrangler 4.131.1, the relevant output was:
Total Upload: 0.17 KiB / gzip: 0.15 KiBNo bindings found.--dry-run: exiting now.Read that line as follows:
Total Uploadis the uncompressed upload size Cloudflare checks against 64 MiB.gzipshows how well the bundle compresses, but it is no longer a deployment-size limit.--dry-runperforms the build and reports the result without publishing a new Worker version.
If Total Upload is below 64 MiB, the Worker bundle-size gate is not the cause of the failure. Continue with the exact error message instead of trying to reduce an already-valid bundle.
Find what makes the bundle large
Start with the files Wrangler produced:
find .wrangler-bundle -type f -exec wc -c {} + | sort -nr | headThen inspect the largest esbuild outputs recorded in the metafile:
jq ' .outputs | to_entries | sort_by(.value.bytes) | reverse | .[] | {file: .key, bytes: .value.bytes}' .wrangler-bundle/bundle-meta.jsonThe metafile helps identify code pulled in by your entry point. Treat it as a diagnostic map rather than an independent limit calculation: Total Upload remains the deployment metric to trust.
Common causes include:
- A large package imported for one small helper.
- Generated data, templates, or lookup tables bundled as source modules.
- Server-only libraries that pull in broad Node.js compatibility code or polyfills.
- Several unrelated features accumulated in one Worker.
- Source maps or generated modules included by a custom build step.
Choose the fix that matches the boundary
Not every Cloudflare size error refers to the Worker bundle. Use the reported metric and error code to choose the right path.
| Signal | Boundary involved | Next step |
|---|---|---|
Total Upload exceeds 64 MiB | Worker code bundle | Remove or replace heavy dependencies, move data out of source modules, or split the Worker. |
| One static file exceeds 25 MiB | Workers Static Assets | Reduce or relocate that asset; changing Worker imports will not fix the asset limit. |
HTTP 413 | Incoming request body | Check the request-size boundary and upload design. |
Error 1102 | Runtime CPU or memory | Profile execution work; shrinking upload bytes alone may not help. |
Total Upload is below 64 MiB | Another deployment problem | Follow the complete Wrangler error instead of treating it as a bundle-size failure. |
For adjacent limits, see the guides to the Cloudflare Pages and Static Assets file limits, Workers 413 request-body errors, and Workers error 1102.
Reduce the Worker without hiding the problem
Replace oversized dependencies
Check whether a dependency is used for a narrow operation that the platform, a smaller package, or a short local function can provide. Also verify that you import a specific module path when the package supports it instead of importing an entire utility suite.
After every change, rerun the same dry-run command. A smaller repository or node_modules directory does not prove that the deployed bundle became smaller.
Move data to the appropriate storage layer
Large JSON tables, media, and generated content usually do not belong inside Worker source code. Depending on access patterns, place them in Workers Static Assets, KV, R2, or D1 and keep only the lookup logic in the Worker.
This changes the architecture, so account for latency, consistency, and storage costs rather than moving bytes blindly. If you choose Static Assets, remember that their file-size and file-count limits are separate from the 64 MiB Worker code limit.
Split unrelated responsibilities
If one deployment contains several independently useful services, separate them into multiple Workers and connect them with Service bindings. This can reduce each bundle and create clearer deployment boundaries, but it should follow actual service boundaries rather than arbitrary file-size slicing.
Review compatibility-induced code
When Node.js compatibility is enabled, inspect the bundle before assuming every imported server package is lightweight on Workers. Wrangler and the runtime may provide compatibility support, while other packages can still bundle fallback implementations or transitive dependencies.
The practical test is the same: compare Total Upload, inspect the metafile, and verify behavior after replacing or removing an import.
Takeaway
For a modern Cloudflare Worker, diagnose “script too large” with the uncompressed Total Upload value from a Wrangler dry run. The limit is 64 MiB for both Free and Paid plans; gzip size is no longer a gate. If the bundle is over the limit, use the generated files and metafile to find imported code, embedded data, or mixed responsibilities before changing the architecture.
FAQ
Does the gzip size count toward the Worker limit?
No. Cloudflare currently enforces the 64 MiB uncompressed Worker size limit. Wrangler still displays gzip size, but Cloudflare documents no compressed-size limit.
Is the 64 MiB limit different on Free and Paid plans?
No. The documented uncompressed Worker size limit is currently 64 MiB on both plan types.
Are Static Assets included in the 64 MiB Worker limit?
Workers Static Assets have separate constraints, including a 25 MiB maximum for an individual asset. Diagnose Worker code with Total Upload, and diagnose asset failures with the asset filename and Static Assets limits.
References:
Report a typo or broken link, or suggest a related topic.