Power Automate: The 100 MB Limit and Chunking as a Workaround (FAQ)

Power Automate limits every single message in a cloud flow to 100 MB, and this limit tends to show up at the worst possible moment: in the middle of emailing a video, uploading a backup to SharePoint, or processing a large collection of PDFs. According to the official Power Automate limits documentation the message size for a single outgoing or incoming HTTP request is 100 MB by default, and with chunking enabled this value can be extended up to 1 GB. As of: July 2026.

This FAQ article summarizes where the limit hits in practice, how chunking works as an official workaround, and where this solution itself reaches its limits. That way, the next time you're dealing with a large file, you'll find the right answer without first clicking through three failed attempts.

What exactly does Power Automate limit to 100 MB?

According to Microsoft, the 100 MB limit applies to the message size of a single outgoing or incoming HTTP request in a cloud flow, i.e. to the entire message body that an action or trigger processes. Important: the limit doesn't apply exclusively to the file itself, but to the entire payload of the request. If you send a file through a connector, according to the documentation the entire payload, including metadata, header information, and any JSON wrapping, must stay under 100 MB, not just the raw file size. A 98 MB file can therefore already fail if additional data is sent along with it.

Why does an even smaller file already hit the limit?

A common stumbling block with SharePoint and OneDrive actions like "Get file content" is encoding. Binary content is often transferred within the flow as a Base64 string, and this encoding increases the data volume by about a third compared to the original file size. A 70 MB file can therefore grow to roughly 90 to 95 MB before it even reaches the actual target action, hitting the 100 MB limit noticeably earlier than the raw file size would suggest. Anyone who regularly works with files in the 60 to 90 MB range should therefore expect problems well before hitting exactly 100 MB.

How does chunking work as an official workaround?

Chunking splits a large message into smaller pieces that are transferred one after another and reassembled at the destination. Power Automate builds on the chunking mechanism of Azure Logic Apps, as the documentation on handling large messages describes: an action first sends an empty POST or PUT request with the headers `x-ms-transfer-mode: chunked` and `x-ms-content-length`, the target endpoint responds with a suggested block size via `x-ms-chunk-size`, and several HTTP PATCH requests follow, each transferring a byte range of the file, until the entire content has arrived at the destination. Downloading large content works the mirror image way, via HTTP GET requests with `Range` headers and responses with status code 206.

Enabling chunking in an HTTP action

In practice, a single click is usually enough: open the HTTP action in the flow designer, go to the settings, and under "Content Transfer" turn on the "Allow chunking" option. Power Automate then handles the splitting automatically, as long as the target endpoint supports the same chunking protocol. An important side effect: once chunking is active for an action, only the raw content data is available in the output; properties like status code or headers are dropped. If you reference those values elsewhere in the flow, for example in tracked properties, that leads to a runtime error, which you should remove beforehand.

Where does chunking itself hit its limits?

• Chunking only works for actions, not for triggers. A trigger like "When a file is created or modified" therefore remains bound to smaller limits, regardless of the chunking settings elsewhere in the flow.
• Even with chunking, the hard upper limit is 1 GB per message. For larger files, the mechanism alone is no longer enough.
• Not every connector and not every external API supports Power Automate's chunking protocol. Custom web services must implement the same protocol, otherwise the splitting has no effect and the request keeps failing.
• Within a flow, overall content throughput still counts: depending on the performance profile, only an additional 200 MB to 10 GB of total data volume is allowed per day across all runs.

What alternative is there for files over 1 GB?

For truly large files, such as video exports or extensive database backups, even enabled chunking eventually stops helping, because the hard 1 GB limit per message still applies. In this case, it's worth taking the detour via an HTTP action that talks directly to the Microsoft Graph API and starts what's called an upload session for the relevant folder there. The file is then uploaded server-side in blocks, without the entire content ever passing through the flow as a single message. You keep control over the process because you manage the block size and retry logic yourself in the flow, instead of relying on a single, risky upload attempt. Where such a solution needs to be set up cleanly and remain maintainable long-term, NordFlux supports the technical implementation as part of its Power Automate consulting.

Frequently asked questions

Does the 100 MB limit apply to every action in Power Automate?

Yes, in principle to every single outgoing or incoming HTTP request within a cloud flow, regardless of whether it's a standard connector or a custom HTTP action. Individual connectors can additionally bring their own, often lower, limits that kick in even before the general 100 MB limit.

What exactly changes when I enable chunking?

The affected action automatically splits large messages into smaller blocks and transfers them one after another, which raises the usable limit from 100 MB up to 1 GB. In return, only the raw content data is available in the action's output; other output properties like status code or headers are dropped.

Does chunking also work with a trigger like "When a file is created"?

No. According to the documentation, chunking can only be set up for actions, not for triggers, because the additional message exchange would create too much overhead there. Very large files therefore remain problematic at triggers, even if chunking is active elsewhere in the flow.

How do I recognize that I've hit the limit?

A typical sign is an error message about a request being too large, or a timeout in the middle of processing, often only after several successful test runs with smaller files. In this case, first check the actual size of the entire payload, not just the original file, and then enable chunking in the action settings, provided the target endpoint supports it.

What do I do with files that exceed 1 GB even with chunking?

In this case, the standard solution from the flow is no longer enough. It makes sense to use an HTTP action that starts an upload session with the Microsoft Graph API and uploads the file server-side in blocks, or a comparable detour via another storage service that handles large files directly, without routing them completely through the flow.