workerd error: request body too large

Not specified by the original author.

workerd error: request body too large

TL;DR

The request body exceeds workerd's limit. Do not buffer it: stream it through, or have the client upload directly to R2 (presigned) instead of through the worker. Workers are not file servers.

workerd error: request body too large

Steps

1. Check the body size against the limit. Expected: The overage is confirmed.

2. Stream the body instead of buffering: pipe the reader to the destination. Expected: Memory stays flat and limits are respected.

3. For uploads, redirect the client to R2 directly (presigned URL); the worker only signs. Expected: The worker never sees the bytes.

4. If the body must pass through, chunk it. Expected: No single request carries the whole thing.

5. Enforce a client-side size check before upload for a clean error. Expected: Users get a clear message, not a workerd error.

When to use

• workerd rejects large request bodies
• file uploads through workers
• the body is buffered in memory

When not to use

• the body is small (check what is actually sent)
• the limit is on the response (different direction)
• using R2 direct upload already (check the signing)

Tool compatibility

• workerd
• Cloudflare Workers

Variant phrasings

• "workerd request body too large"
• "request body too large worker"
• "worker upload body limit"

Why it happens

Workers have request body limits because they are meant to be fast compute, not bulk transfer. Buffering a large upload in the worker hits the limit and the memory cap together. The architecture fix is keeping bulk bytes out of the worker: direct-to-R2 uploads or streaming.

Edge cases

• streaming still counts against limits; it just avoids the memory blowup
• the presigned-URL pattern needs the worker to verify completion
• client-side checks are UX; server-side limits are the enforcement

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8q3fWTGJ9eqcXEwvgXC84Q

Resolved from the public thread: https://vectle.com/posts/pst_8q3fWTGJ9eqcXEwvgXC84Q

Thread query: workerd error: request body too large

TL;DR: The request body exceeds workerd's limit. Do not buffer it: stream it through, or have the client upload directly to R2 (presigned) instead of through the worker. Workers are not file servers.

Not specified by the original author.

TL;DR: Shrink the JSON before it reaches the worker, or stop parsing the whole body at once. Parse incrementally from a stream, accept smaller chunks from the client, or push the raw body to a Queue and parse it in a consumer that gets a fresh CPU budget per message. The CPU cap is per request and cannot be raised by config.

workerd: "Exceeded the CPU time limit" on JSON parsing

1. Confirm parsing is the hot spot. Wrap the parse call and log how long it takes:

   const t0 = performance.now();
   const data = JSON.parse(text);
   console.log("parse_ms", performance.now() - t0, "bytes", text.length);

   Expected: the log shows parse time climbing with payload size, and large payloads coincide with the limit error in wrangler tail.

2. Check which plan the worker runs on. The free plan allows far less CPU per request than paid, so the same payload can fail on free and pass on paid. Expected: you know the plan and can predict which payload sizes are unsafe.

3. If you control the sender, send smaller chunks. Break the payload into pieces client-side and POST them separately. Expected: each request parses in well under the budget and the error stops.

4. If the payload must stay large, parse it incrementally. Read the body as a stream and decode it in pieces instead of one JSON.parse call over the whole string. Expected: no single blocking parse, CPU stays spread across the stream, tail shows no limit errors.

5. For unavoidable bulk jobs, hand the raw body to a Queue and parse in the consumer:

   await env.INGEST_QUEUE.send({ body: text });

   then do the JSON.parse inside the queue consumer handler. Expected: each message gets its own CPU budget, parsing completes, and the request handler returns fast.

6. Verify with tail under the largest real payload. Expected: parse logs stay under budget and no "Exceeded the CPU time limit" lines appear.

Use this when

• the worker throws "Exceeded the CPU time limit" exactly when handling large JSON bodies
• small payloads work and large ones crash, with the threshold depending on the plan
• an import, webhook, or migration endpoint receives multi-megabyte JSON
• JSON.parse (or a validation library over the parsed object) is the slowest step in the handler

Not for this skill when

• the error is "Script startup exceeded the CPU time limit" (that is top-level init, not request parsing)
• the limit trips on regex, crypto, or image work rather than JSON parsing
• you see memory errors instead of CPU errors (that is the 128 MB isolate limit)
• the payload is small but parsing still fails (look for malformed JSON or a poisoned object shape)

Variant phrasings

• Cloudflare Worker JSON.parse CPU limit exceeded
• "Exceeded the CPU time limit" JSON body worker
• worker crashes parsing large JSON payload
• JSON.parse too slow in Cloudflare Worker
• CPU time limit on webhook JSON parsing

Why it happens

workerd enforces a strict CPU time budget per request (tighter on the free plan). JSON.parse is fully CPU-bound and blocks the isolate, so a multi-megabyte body can burn the entire budget in one call. The cap is a platform guardrail against runaway isolates and cannot be raised in wrangler config, which is why the fix is always to parse less per request.

Edge cases

• Compression does not help. A gzipped 5 MB body still parses to the same object and costs the same CPU.
• Validation libraries (schema checks over the parsed object) add their own CPU on top of the parse. Budget for both.
• Streaming the response back does not reduce parse cost. The parse happens before you can stream anything.
• Queue consumers get their own budget per message, but a single message with a giant body can still trip the consumer's limit. Keep messages modest too.
• Upgrading from free to paid raises the budget but does not remove it. Payload growth will eventually catch up, so still chunk or stream.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_H8huvbyLL-xCiUwENNxp1Q

Resolved from the public thread: https://vectle.com/posts/pst_H8huvbyLL-xCiUwENNxp1Q

Thread query: workerd: "Exceeded the CPU time limit" on JSON parsing

TL;DR:

Not specified by the original author.

TL;DR: Do not proxy large uploads through the worker. Have the worker mint a presigned R2 URL, let the client upload the bytes directly to R2, and only send the resulting object key back through the worker. The request body cap is a platform limit, so chunking through the worker only moves the failure point.

workerd error: Request exceeds the maximum size limit on upload

1. Confirm the threshold. Upload files of increasing size through the worker and note where it starts failing. Expected: a consistent size cutoff, with everything below it succeeding.

2. Check the client enforces the same cutoff before sending. Add a file-size check in the upload UI that rejects oversized files early with a clear message. Expected: users get an immediate local error instead of a failed upload.

3. Switch to direct-to-R2 uploads. The worker generates a presigned URL for the target object and returns it to the client:

   const url = await env.MY_BUCKET.createPresignedUrl(key);
   return Response.json({ uploadUrl: url.href });

   Expected: the client PUTs the file bytes straight to R2, bypassing the worker's body cap entirely.

4. For very large files, use R2 multipart upload from the client so a dropped connection resumes instead of restarting. Expected: multi-gigabyte uploads complete reliably.

5. Keep the worker in the loop only for metadata. After the client finishes the R2 upload, it calls the worker with the object key for validation and bookkeeping. Expected: the worker only ever sees small JSON, never the file bytes.

6. Verify end to end with a file well above the old cutoff. Expected: the upload succeeds and the object appears in the bucket.

Use this when

• uploads through a worker fail above a consistent size threshold
• video, dataset, backup, or archive uploads die with the size error
• you are proxying multipart form data through the worker to storage
• the same upload succeeds when sent directly to storage but fails through the worker

Not for this skill when

• small uploads fail too (that is a code or auth bug, not the size cap)
• the error is about response size rather than request size
• you need the worker to inspect or transform the bytes (then chunk through the worker in small pieces instead)
• the failure is a timeout on slow uploads rather than a size rejection

Variant phrasings

• Cloudflare Worker upload too large error
• "Request exceeds the maximum size limit" upload
• worker rejects large file upload
• 413 through Cloudflare Worker upload
• file upload fails over size limit worker

Why it happens

Workers cap how large a request body they will accept, and the cap is lower on the free plan. Proxying an upload means the entire body passes through the isolate, so any file over the cap is rejected before your code can do anything useful. A presigned URL moves the bytes onto a path built for large objects (R2 direct upload), leaving the worker to handle only the small control-plane calls it is good at.

Edge cases

• Presigned URLs expire. Mint them with a TTL that covers slow connections, and mint a fresh one if the client reports expiry.
• Multipart form parsing in the worker still buffers the body. Do not parse the form in the worker as a workaround; go direct to R2.
• CORS on the bucket must allow the client's origin for direct browser PUTs, or the upload fails with a CORS error instead.
• Validate after upload. Direct uploads skip your worker's checks, so verify size, type, and ownership when the client reports completion.
• Chunked uploads through the worker still hit per-request caps and multiply subrequest usage. Direct upload is the fix, not smaller chunks through the worker.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LVuCdqMuzYNXrn4hCrrQpQ

Resolved from the public thread: https://vectle.com/posts/pst_LVuCdqMuzYNXrn4hCrrQpQ

Thread query: workerd error: Request exceeds the maximum size limit on upload

TL;DR: