Handle Large Files in Power Automate with Chunking

Large files have a way of breaking Power Automate flows that worked perfectly on your test documents. You build everything with a small sample, ship it, and then someone runs it against a 90 MB file and the whole thing falls over with a cryptic error. The culprit is almost always the same: Power Automate has strict limits on how much data a single action can move, and big files blow straight past them.

Chunking is the mechanism that is supposed to help, but it comes with its own quirks. Let me walk you through what chunking actually does, the real size limits you are fighting, when to turn it off, and what to reach for when the connector simply cannot cope.

What Chunking Actually Is

When you upload or download a file with the SharePoint or OneDrive connector, the whole file has to pass through your flow as a single message. Power Automate caps that message at 100 MB, and any action that tries to carry more than that fails.

Chunking splits a large transfer into smaller pieces that travel separately and reassemble at the destination. Microsoft's own guidance treats anything over roughly 30 MB as large and starts splitting it into chunks behind the scenes. You do not see the individual pieces. The action just handles bigger files than it otherwise could.

Two things are worth knowing up front. Chunking works on actions only, never on triggers, so a trigger like "When a file is created" still skips files over 50 MB. And chunking is not magic. It raises the ceiling, but it introduces behaviors that can surprise you, which is where most of the pain comes from.

The "Allow Chunking" Toggle

You control chunking per action. Open the action (for example, the "Create file" action), go to Settings, and look under Content transfer for the "Allow chunking" toggle.

Here is what actually changes when you flip it:

• With chunking off, a single action can move up to 100 MB. That is the hard message limit.
• With chunking on, the same action can move up to 1 GB (1,073,741,824 bytes), because the file travels in pieces.

The default chunk size depends on your environment. On standard cloud flows it varies by connector, and on single-tenant it defaults to about 52 MB per chunk. You rarely need to touch the size itself. The toggle is the part that matters.

One more gotcha lives in the "Get file content" action. It returns file data as Base64, which inflates the size by roughly a third. So a file that is 75 MB on disk can push a flow past the 100 MB message limit once it is encoded, and you hit a "413 Request Entity Too Large" error well before you expected to.

The Overwrite Trap

Here is the one that catches almost everyone. When chunking is on, the "Create file" action has no overwrite option, so re-running a flow against an existing file fails with "A file with the name already exists." To get the Overwrite toggle back, you have to turn Allow chunking off, which drops you back to the 100 MB limit.

There are also scattered reports of files landing in the library but arriving corrupt when they sit right on the chunking threshold, especially images coming from Power Apps. If you are handling sub-100 MB files and seeing corruption, turning chunking off is the quickest thing to try.

When the Connector Isn't Enough: Microsoft Graph

Once you genuinely need files larger than the connector can handle, or you need reliable overwrites and the ability to resume a failed transfer, it is time to leave the standard actions behind and talk to Microsoft Graph directly. You can do this with HTTP actions or the "Send an HTTP request to SharePoint" action, and I cover the setup in How to call Microsoft Graph API from Power Automate.

Graph uses an upload session. You create the session with a POST, and Graph hands back a preauthenticated upload URL. You then send the file in fragments with PUT requests, each carrying a "Content-Range" header that tells Graph which bytes it is receiving.

A few rules keep this working:

• Every fragment except the last must be a multiple of 320 KiB (327,680 bytes). Send an odd size and the final commit fails.
• Each request must stay under 60 MiB. Microsoft recommends 5 to 10 MiB per fragment.
• Do not send an Authorization header on the PUT requests. The upload URL is already authenticated, and adding your own header returns a 401.

The payoff is real. Upload sessions are resumable, handle very large files, and let you set the conflict behavior to fail, replace, or rename.

The Older SharePoint REST Route

Before Graph became the recommended path, SharePoint exposed its own chunked methods: "StartUpload", "ContinueUpload", and "FinishUpload", tied together by a GUID you generate for the session. You start the upload with the first fragment, continue with each middle fragment at the right byte offset, and finish with the last one to commit the file.

These still work through the "Send an HTTP request to SharePoint" action, but they are fiddly (you manage the offset math yourself in a loop) and Microsoft has quietly steered everyone toward Graph. I would only use them if you are already deep in SharePoint REST and have a reason to stay there.

A Quick Decision Guide

Most of the time you do not need any of the advanced routes. Here is how I choose:

• Under 50 MB, creating a new file: standard "Create file" action, leave chunking on.
• 50 to 100 MB and you need to overwrite: turn chunking off and use the Overwrite toggle, or delete then create.
• 100 MB to 1 GB: keep chunking on, and remember you cannot overwrite in the same action.
• Over 1 GB, or you need resume and reliability: use a Graph upload session.
• Copying an existing large file: use the "Copy File" action, which sends a reference instead of moving the bytes through your flow.

Final Thoughts

Chunking is one of those features that quietly does its job until the day it does not. The mental model that keeps you out of trouble is simple: the connector moves up to 100 MB on its own, chunking stretches that to 1 GB but blocks overwrites, and Microsoft Graph is where you go when you need real size, resumable transfers, or dependable replacements. Match the tool to the file, and large files stop being the thing that breaks your flows.

Photo by Alicia Christin Gerald on Unsplash