Cloudflare Workers 413: Find the Request Body Limit Before Rewriting Uploads

Start with the three possible limits#

There are several limits that are easy to conflate:

Cloudflare’s current Workers limits list a maximum request body of 100 MB for Free and Pro, 200 MB for Business, and 500 MB by default for Enterprise. Those values are plan-dependent and can change, so treat the Workers limits page as the source of truth rather than copying a number into an application constant.

Cloudflare’s 413 troubleshooting page describes a second boundary: the zone’s Maximum Upload Size can reduce the effective upload limit, and Cloudflare API uploads have plan-dependent limits. An origin can impose a third limit after the request passes through the edge.

Identify who returned the 413#

Reproduce the failure with a known-size test file and preserve the response headers:

1
curl -i -X POST -H 'Content-Type: application/octet-stream' --data-binary @sample-120mb.bin https://api.example.com/upload

Record:

1. The exact hostname and path.
2. The request size in bytes.
3. Whether the request is proxied through Cloudflare.
4. The response status, headers, and body.
5. Whether a Worker invocation, origin access log, or application log was created.

If there is no Worker invocation and no origin log, the rejection is probably upstream of your handler. If the Worker log exists but the origin log does not, inspect the Worker route, request forwarding, and any explicit size guard. If the origin log shows the request and returns 413, fix the origin’s body limit instead of changing Cloudflare’s plan.

Do not use only a browser upload for this test. Browsers may retry, send multipart boundaries, or hide the exact response body. A repeatable curl request gives you a size boundary you can move up and down.

Keep the Worker handler bounded#

For a small JSON endpoint, validate the declared content type and size before parsing:

1
const MAX_JSON_BYTES = 1024 * 1024;
2

3
export default {
4
  async fetch(request) {
5
    const contentLength = Number(request.headers.get('content-length') || 0);
6

7
    if (contentLength > MAX_JSON_BYTES) {
8
      return Response.json(
9
        { error: 'Request body is too large for this endpoint.' },
10
        { status: 413 },
11
      );
12
    }
13

14
    if (request.headers.get('content-type')?.includes('application/json') !== true) {
15
      return new Response('Unsupported content type', { status: 415 });
16
    }
17

18
    const body = await request.json();
19
    return Response.json({ received: body });
20
  },
21
};

This application-level check is useful for a predictable API contract, but it is not a replacement for the edge limit. A missing or misleading Content-Length header is not proof that the body is small, so the handler still needs a safe parsing strategy for its endpoint.

Avoid calling request.arrayBuffer() or request.text() on unbounded uploads. Buffering a large body consumes Worker memory and can turn a request-size problem into a memory problem. If the application needs the body, stream it or cap the route before parsing.

Move browser uploads directly to R2#

When the Worker only authenticates the user and stores a file, proxying the entire file through the Worker adds an unnecessary request hop. Cloudflare’s R2 docs support a presigned PUT URL for a single object:

1
// Server-side sketch: create a short-lived, content-type-bound PUT URL.
2
const uploadUrl = await createPresignedPutUrl({
3
  bucket: 'uploads',
4
  key: 'user-123/photo.png',
5
  contentType: 'image/png',
6
  expiresIn: 900,
7
});
8

9
return Response.json({ uploadUrl });

The browser then uploads directly:

1
const response = await fetch(uploadUrl, {
2
  method: 'PUT',
3
  headers: { 'Content-Type': file.type },
4
  body: file,
5
});
6

7
if (!response.ok) {
8
  throw new Error('R2 upload failed');
9
}

The signing code must stay on the server, and the URL should be scoped to one object, one operation, and a short expiry. Configure bucket CORS for the browser origin and treat the URL as a bearer token. If uploads need resumability or parallel parts, use R2’s multipart upload path rather than pushing one huge body through a Worker.

The R2 presigned URL documentation notes that presigned URLs support PUT for object uploads, while HTML form POST uploads are not currently supported. Pick the client method that matches the storage API instead of assuming every S3 upload example works unchanged.

After changing the upload path, exercise the built Worker route with the production-build request harness described in Cloudflare Workers createTestHarness(). The test should cover an accepted small request, an application-level 413, and a direct-storage upload failure.

Re-test the boundary, not only the happy path#

Use files just below and just above the application limit, then test the Cloudflare and origin limits separately. A useful matrix looks like this:

Keep the original response headers and logs with the deployment change. If a future plan or zone setting changes, those records show which layer changed rather than leaving a vague “Cloudflare upload failed” report.

FAQ#