Make.com's file size limit isn't your video. Pass a URL instead.

Your Make.com scenario worked fine on a 40 MB test clip. Then a real 800 MB webinar recording came through, and the HTTP module returned Maximum file size exceed error, or the whole scenario died at the 40-minute mark. Both failures have the same cause, and it isn't the video.

Quick answer: Make.com's file size limit is set by your plan, not by your video, and it applies to any file a module holds in scenario memory. Free plans fail around 5 MB, Core users report errors near 100 MB, and the top tier caps at 1 GB. The workaround is to never download the video into Make at all: send the file's URL to a video-processing API with one HTTP module, poll until the job finishes, then map the returned output URL back into your scenario. The bytes stay in cloud storage, so a 4 GB source moves through a scenario that only ever handles a few KB of JSON.

Why Make.com breaks on video (it's not the file size)

Conventional wisdom says Make can't handle big video, so you should compress before it hits the scenario. That's partly true, and it's also the wrong fix. The problem isn't that the file is large. It's that Make modules pass binary data between each other as a buffer in scenario memory, and that buffer is metered against your plan.

The moment you use Google Drive > Download a File, or HTTP > Get a File, you've pulled the entire video into Make's execution memory. Every downstream module now carries it. Compressing first just moves the ceiling; you'll hit it again on the next long recording.

Make's own documentation states plainly that the maximum file size depends on the plan you are subscribed to. Community threads fill in the numbers:

In one Make Community thread, a user on the Free plan tried to pull a 13 MB file through HTTP > Get a File and got Maximum file size exceed error. A moderator explained why the same file worked through the Google Drive module: "HTTP is an internal integration, hence the limit enforcement." Different modules, different enforcement, same underlying buffer.

The second wall is time. Make caps scenario execution at 40 minutes. Transcoding an hour-long 4K recording takes longer than that on any realistic pipeline, so even if you somehow got the bytes in, you'd hit MAXIMUM EXECUTION TIMEOUT [40 minutes] on the way out.

The two errors, and what each one means

Maximum file size exceed error means a module tried to load a file larger than your plan allows. It fires at download time, before any processing happens. Upgrading buys you headroom, not a solution.

Module timed out or the 40-minute scenario timeout means the work itself took too long. This one shows up even on files well under your cap, because video processing time scales with duration and resolution, not file size.

The fix: keep the bytes out of Make entirely

Make is good at orchestration and bad at holding gigabytes. So don't ask it to. Treat the video as a URL that Make passes around, and let a dedicated service do the actual FFmpeg work.

This is the same pattern that fixes n8n timeout errors when processing video. The automation tool never touches the media.

Build it in Make: the URL handoff scenario

Six modules. No file downloads anywhere.

1. Trigger on the file, not the bytes

Use Google Drive > Watch Files, Dropbox > Watch Files, or a webhook from your uploader. Take the file ID and metadata. Do not add a Download module.

2. Get a real direct-download URL

This trips people up. A Google Drive sharing link (https://drive.google.com/file/d/FILE_ID/view) returns an HTML page, not a video. Convert it to https://drive.google.com/uc?export=download&id=FILE_ID, or better, use an S3/GCS presigned URL with at least an hour of validity. The processing API has to be able to fetch the file on its own.

3. Submit the job with HTTP > Make a Request

Method POST, URL https://api.ffmpeg-micro.com/v1/transcodes, body type Raw, content type JSON. Add a header Authorization: Bearer YOUR_API_KEY.

{
  "inputs": [
    { "url": "https://your-bucket.s3.amazonaws.com/raw/webinar-0817.mp4" }
  ],
  "outputFormat": "mp4",
  "preset": {
    "quality": "medium",
    "resolution": "1080p"
  }
}

Turn on "Parse response" so Make gives you mapped fields instead of a string. You get back a job immediately:

{
  "id": "job-uuid",
  "status": "pending",
  "inputs": [{ "url": "https://your-bucket.s3.amazonaws.com/raw/webinar-0817.mp4" }],
  "output_format": "mp4",
  "created_at": "2026-08-07T14:22:10Z"
}

That request took under a second and moved roughly 300 bytes through Make. The 800 MB webinar never entered the scenario.

4. Wait

Add a Sleep module set to 30 seconds. Make's Sleep module maxes out at 300 seconds per run, so use a Repeater around steps 4 and 5 if you need longer.

5. Poll for status

HTTP > Make a Request, method GET, URL https://api.ffmpeg-micro.com/v1/transcodes/{{1.id}}, same Bearer header.

{
  "success": true,
  "jobId": "job-uuid",
  "status": "completed",
  "outputUrl": "https://storage.googleapis.com/output-bucket/webinar-0817-1080p.mp4",
  "createdAt": "2026-08-07T14:22:10Z",
  "completedAt": "2026-08-07T14:24:40Z"
}

Status values are queued, processing, completed, and failed. Put a filter after this module that only continues when status equals completed, and route failed to your error handler.

6. Map the output URL downstream

Feed outputUrl straight into your Slack post, Airtable record, YouTube upload, or CMS. Most upload modules accept a URL. If one insists on a file, that's the only point where you download, and by then the video is already compressed to a size your plan can hold.

The FFmpeg command you'd otherwise be running

If you were self-hosting this, the transcode step looks like:

ffmpeg -i webinar-0817.mp4 \
  -vf scale=-2:1080 \
  -c:v libx264 -preset medium -crf 23 \
  -c:a aac -b:a 128k \
  webinar-0817-1080p.mp4

Now add a server to run it on, a queue so concurrent uploads don't thrash the CPU, disk for the intermediate files, and monitoring for when a job wedges. That's the total cost of ownership Make users are trying to avoid in the first place. The API call above replaces all of it, and it's the same one call whether you're resizing, compressing for the web, or burning in captions.

Common pitfalls

When to skip this and do something else

If your videos are consistently under 50 MB and you're on Core or above, keep it inline. The extra modules aren't worth it for short social clips.

Check the input cap on whatever API you pick, too. FFmpeg Micro's free tier accepts inputs up to 250 MB with 100 processing minutes per month, Starter handles 1,024 MB, Pro 2,048 MB, and Scale 5,120 MB. A 6 GB drone master exceeds every tier, so split it before upload or handle it outside an automation tool.

And if the job isn't really processing, pick the right category of tool. Mux and Cloudflare Stream are built for adaptive-bitrate streaming delivery. AWS Elemental MediaConvert is built for broadcast-grade encoding ladders with an AWS-shaped operational burden to match. A media API makes sense when you want transcoding, captions, watermarks, or clip assembly as a step inside a workflow you already run.

FAQ

What is the maximum file size Make.com can handle?

It depends on your plan. Free plans hit Maximum file size exceed error around 5 MB, Core users report failures near 100 MB, and the top tier caps at 1 GB. The limit applies to any file held in scenario memory, which is why the fix is to pass URLs instead of files.

How do I process a video in Make.com that's too large?

Send the video's public or presigned URL to a video-processing API using HTTP > Make a Request, poll the job status endpoint until it returns completed, then map the returned outputUrl into your next module. Make handles only JSON, so your plan's file size limit never applies.

Why does my Make.com scenario time out on video?

Make caps scenario execution at 40 minutes. Transcoding a long or high-resolution video takes longer than that, so the scenario dies before the module returns. Submitting an async job and polling for the result, or splitting submit and check into two scenarios, keeps every run well under the cap.

Can Make.com compress video without an external service?

No. Make has no native encoding module, so any compression has to happen in an app connector or an external API. Sending the file to a transcoding endpoint and getting a URL back is the shortest path, and it's the same approach used to compress video for the web at a target bitrate.

Does this work in Zapier and n8n too?

Yes. The pattern is a plain HTTP request plus a status poll, so it drops into n8n's HTTP Request node or Zapier's Webhooks by Zapier action with the same JSON body and the same two endpoints.

You can wire the whole thing up on the free tier and see whether a URL handoff clears your file-size error before you touch your Make plan. Sign up free, grab an API key, and paste the two HTTP modules above into your existing scenario.