Copilot Studio Agent Unable to Retrieve Usable DOCX/XLSX Content from OneDrive (and SharePoint)

This is a platform limitation, not a file problem. When OneDrive or SharePoint Get file content is added directly as an agent tool, Copilot Studio turns the binary output into a text string. Bytes that aren't valid text get replaced with the ? character, so the DOCX/PDF is permanently corrupted. The poster's own tests in the thread confirm this: txt and md files came back fine, docx and pdf didn't, with both connectors. No admin setting fixes it. The "enable a binary-preserving download path" message one person got is just the model guessing, not a real switch.

The fix is to stop exposing Get file content directly as a tool. Which option to use depends on what the agent actually needs.

Option 1: The agent needs to understand what's in the file (most common)

This needs no binary handling at all:

• Add the OneDrive/SharePoint folder as a Knowledge source. Copilot Studio indexes docx, xlsx and pdf text itself, and the agent can answer questions from it directly.
• For Excel data: use Excel Online (Business) → List rows present in a table inside an agent flow, and return the rows as JSON. The data has to be formatted as an Excel table.

Option 2: The agent needs the actual file (e.g. code interpreter with python-docx/openpyxl)

Wrap the download in an agent flow so the file comes back as base64 text, which survives the conversion:

1. Copilot Studio → Tools → Add a tool → New agent flow.
2. Trigger: When an agent calls the flow, with an input such as FilePath (or file ID).
3. Action: OneDrive for Business → Get file content using path (or SharePoint → Get file content).
4. Respond to the agent with a Text output FileBase64 set to this expression:

body('Get_file_content_using_path')?['$content']

For binary files this property is already base64. If it comes back empty, use base64(body('Get_file_content_using_path')) instead.
5. Add a second output FileName so the code knows the extension.
6. In the agent instructions, add something like: "The file tool returns base64. Decode it with base64.b64decode() and save it as a file before opening it with python-docx/openpyxl."

Caveat for Option 2: base64 is about 33% bigger than the original file, and it all goes into the model's context. A 14 KB docx is fine; files of several MB will hit tool-response or token limits. For larger files, do the extraction inside the flow (Option 1 style) rather than passing the whole file to the agent.

Quick fix to try first

Open the existing Get file content tool → Inputs → set Infer Content Type = No. Sometimes this changes the response shape, but it doesn't reliably stop the text conversion. Treat Option 2 as the real fix.

I have a similar issue using a workflow trigger on a OneDrive folder to pick up an XLSX file and pass the contents to a Copilot step.  Sometimes the CoPilot steps works and is able to read the data, other times I see the error you all are seeing.  I tried setting Infer Content Type to false in the trigger but still not working?

Hello, I am having a same issue as the above. Copilot Studio suggests me that I should ask Copilot Studio agent maker or administrator to enable binary-preservering download path for "get_file_content" connector or expose infer_content_type as adjustable. Do you know how exactly should I request to our Copilot administrator?

hi edfencer​ The behavior described here points more toward binary content handling than an issue with the DOCX/XLSX files themselves.

The fact that test.txt comes back correctly, while the DOCX response starts with PK but contains “?” replacement characters, is a strong indication that the binary file is being interpreted as text somewhere in the Copilot Studio/Power Automate flow. Once the binary data has been decoded as text, the original bytes can be lost, which would explain why python-docx or openpyxl cannot open the reconstructed file.

A few things are worth checking:

• Confirm the output type of the OneDrive Get file content action. It should remain binary rather than being converted to a string.
• Avoid passing the file content through variables, JSON parsing, string manipulation, or other steps that may implicitly convert binary data to text.
• If the content needs to be passed to Python or another service, send it as binary or base64, rather than copying the displayed text representation.
• Test the same approach with a small DOCX/XLSX file to rule out payload-size or connector limitations.
• Check whether the same behavior occurs when using SharePoint - Get file content instead of OneDrive. If both behave the same way, that would further suggest an issue with how the flow/action is exposing binary content rather than with OneDrive itself.

One important point: seeing PK at the beginning doesn't necessarily mean the binary content is intact. The “?”characters are a good indication that some bytes have already been incorrectly decoded as Unicode, and those original byte values generally cannot be recovered reliably from that string.

If the requirement is for the agent to understand the contents of DOCX/XLSX files, another approach may be preferable to passing the raw Office file to Python. For example, extract the document text or Excel data first and pass the structured content to the agent. If the actual requirement is to preserve and process the original file, however, the binary/base64 representation needs to be maintained end-to-end.

It would also be useful to check the exact output schema returned by Get file content and how that output is being passed to the next action. That should help identify exactly where the binary-to-text conversion is occurring.