Large files break automations. Pass links, not bytes

A 40 MB invoice PDF does not break your automation because it is 40 MB. It breaks because six steps each materialized their own copy, base64 encoding added about a third to every copy, and the platform kept all of it in the execution record after the run finished. The number that matters is not the file size. It is the file size multiplied by the number of steps that hold the bytes. The fix is not a bigger server: upload the file to storage once, pass a URL or an object key between steps, and let exactly one step ever touch the actual file.

Why a 40 MB PDF costs you 500 MB

Workflow platforms do not stream files through your steps. They hand each step a data item, and if that item contains the file, the file exists again.

n8n's own hosting documentation is direct about this. It keeps binary data in memory by default, and it says outright that the default "can cause crashes when working with large files." The documented fix is to set N8N_DEFAULT_BINARY_DATA_MODE to filesystem, or to database if you are running queue mode. That is real and worth doing, but read what it actually does. It moves the copies off the heap and onto disk. It does not stop them being made.

So do the arithmetic before you build. Take the file size, multiply by the number of steps that materialize it, multiply by roughly 1.33 if it is riding inside the step's JSON data, and multiply again by the number of items in a single run. Twenty-five invoices at 8 MB each, moving through five steps, is a gigabyte of live data in one execution. Nobody planned that. It got built one node at a time, and it worked fine in testing on a 200 KB sample.

Then the run ends and the data does not go away. Execution history retains what the run produced, so a workflow that materializes files is also quietly buying storage every time it fires. Set a retention window on execution data deliberately rather than discovering it in a disk alert.

Hosted platforms hide the memory question from you and hand you a hard ceiling instead. Zapier's platform documentation states a hard limit of 150 MB on the size of dehydrated files, and warns that problems start well below that, advising integrations not to hydrate files larger than about 100 MB. When you cross it you do not get a helpful message about file size. You get a timeout or a generic 400.

Airtable's own API is the proof: 5 MB by bytes, 5 GB by link

If you want a single piece of evidence for the whole design rule, it is in Airtable's documentation, and it is a thousandfold gap inside one product.

Airtable's upload attachment endpoint describes itself precisely: upload an attachment up to 5 MB to an attachment cell "via the file bytes directly." Five megabytes. That is a phone photo and a half.

The same attachment field, on the same account, accepts individual attachments up to 5 GB when the file arrives by URL. On the Free plan that per-file ceiling is 1 GB.

How the file reaches Airtable	Per-file ceiling
Direct byte upload, base64 through the upload endpoint	5 MB
Attachment added by URL	5 GB (1 GB on Free)

Same field. Same permissions. Same plan. The only variable is whether your automation carried the bytes or carried a link, and that decision costs you three orders of magnitude of headroom. Most teams hit the 5 MB wall, conclude that Airtable cannot handle their files, and go looking for a different database. The database was never the constraint.

The base64 tax is already priced into vendors' published limits

Here is why moving bytes costs more than the file weighs. Steps pass structured data, almost always JSON, and JSON has no binary type. A file traveling inside a step's data gets base64-encoded. Base64 represents each 24-bit group of input, meaning three bytes, as four output characters. Four out for every three in, before JSON escaping and before the rest of the payload.

You can see that tax in numbers vendors publish. In the rollout that started February 23, 2026, Google raised Gmail's attachment limits for Workspace Enterprise Plus: sending went from 25 MB to 50 MB, and the receiving limit went to 70 MB. A 40 percent gap between what an account can send and what it can receive is about the shape of the encoding overhead, because the receiving ceiling is measured on the encoded message and the sending one is measured on the file you dragged in.

The operator version of that rule: whatever ceiling a service publishes, budget about 75 percent of it for the real file if your automation is encoding it. A 45 MB video that "fits" a 50 MB limit does not fit.

Build so exactly one step ever holds the bytes

Four rules, in the order you apply them.

Make the trigger carry a reference. Configure the source to send a file ID or URL, not the file. If the source is a form that posts the file directly, the first job of the workflow is to land that file in object storage and keep only what comes back.

Store once, at the edge. Upload at the earliest step that can reach the file, then explicitly drop the binary from the item. In n8n this means an Edit Fields step that keeps the URL and removes the binary property, because binary data rides along by default until you remove it. Skipping this is the most common version of the bug: the file was uploaded to S3 at step 2 and also carried through steps 3 to 9.

Pass the key internally, mint the link late. Move the storage key or object path between steps and generate a short-lived signed URL only at the step where a third party has to fetch the file. This keeps you from writing long-lived public URLs into a CRM record where they will outlive the reason they existed. When you log the run, log the object key. Never log the signed URL and never log the file.

Name the one step allowed to materialize. Write it down. If two steps need the raw bytes, that is a signal they should be one step. Two separate downloads of the same file is a design mistake, not a requirement.

Ask the destination first, before any of this. Most systems that operators actually write to, including CRMs, spreadsheets, chat tools, and document stores, accept a URL. Where a destination takes a link, sending bytes buys you nothing and costs you a ceiling. This is one of the first things we check when we audit a workflow that keeps failing under load, and it is especially common in field and jobsite operations, where crews upload full-resolution photos from phones and nobody notices until a run carries thirty of them.

When you genuinely need the bytes

The reference pattern is not universal. Some work requires the file itself, and pretending otherwise produces a design that cannot do its job.

You need the real bytes for OCR and vision extraction, checksums and hashing, virus scanning, zipping and unzipping, and any format conversion. Those steps read content. A URL is not content.

You also need them when a destination only accepts bytes and you have no publicly reachable URL to hand it. Airtable's 5 MB endpoint is exactly that case. So are plenty of smaller SaaS APIs. When you hit it, the answer is a chunked or resumable upload against that one API, run in a step that has real disk, and not an attempt to push the whole thing through a general-purpose workflow node.

The rule survives both cases, because the point was never to avoid downloading files. It was to download each one once, in a place you chose on purpose.

How to check your own workflow in ten minutes

Open the largest recent successful execution of the workflow that touches files and read down the step list, looking at the data size on each step. If the file's size appears more than once, you have found your multiplier. Count the steps between where the file enters and where it is finally consumed. Every one of those is a copy you can delete by swapping in a URL, and that is usually an afternoon of work rather than a rebuild.

Then run the ceiling check. Take the largest file a real customer could plausibly send you, not your test file, multiply it by 1.33, and compare that number to the published limit of every service in the chain. If you are within 25 percent of any of them, you do not have a working automation. You have one that has not met a big file yet.

If that check comes back badly and the workflow is already running in production, the safe order is to add the storage step first, verify it writes correctly for a few days while the old path still works, and only then start removing the binary from the items in between. If you want a second read on where your file path is holding copies, send us the step list and we will tell you which steps to cut.