# 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.

```text
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