Forum Discussion
Excel Copilot fails when local workbook filename contains #
Excel Copilot does not work with locally stored workbooks whose filename contains the '#' character. The same workbook works correctly after renaming the file to remove '#'. The same workbook also works when stored on OneDrive with '#' in the filename. The issue appears specific to local files and filename parsing.
Specifically, when clicking on Copilot in Excel, Copilot says "This file type is not supported for editing with Copilot. Please save this file as a modern file format, such as ".xlsx", to be able to edit it with Copilot."
Interestingly, Copilot works fine if the Excel file name contains, for example, % or &, the problem only occurs if the name contains #. We suspect this is a bug. In our workflows, we work a lot with files that have # in their names and we would be very happy if this was indeed a bug and if it was fixed. Tnx.
8 Replies
Worth trying below:
- Rename local files: Remove # from filenames when working locally.
- Store files in OneDrive/SharePoint: Copilot correctly handles # in filenames when files are cloud‑stored.
- File naming policy: For compliance workflows, adopt a naming convention that avoids reserved characters (#, ?, *, :) in local filenames.
Kidd_Ip, your breakdown is spot-on and incredibly practical. I particularly appreciate how clearly you distinguished the local workaround (renaming) from the officially supported cloud workflow (OneDrive/SharePoint). That was exactly the nuance I needed to reinforce in my original reply. Your suggestion to adopt a file-naming policy that avoids reserved characters is simple yet brilliant – it’s a proactive habit that will save teams from running into this and similar issues down the line.
Patrick2788, thank you for that fascinating historical context! Knowing that # caused headaches back in the SkyDrive days makes so much sense now. It really highlights that this isn't a brand-new quirk, but rather a long-standing parsing behavior deeply tied to how Microsoft handles URIs and file paths. Your insight perfectly explains why this bug keeps resurfacing and adds even more weight to Kidd Ip policy recommendation – if it's been problematic for over a decade, avoiding it entirely is clearly the safest bet.
Together, you’ve given the definitive answer for anyone facing this issue: rename locally, store in the cloud for full support, and adopt a safe naming convention going forward.
Thanks again for taking the time to share your expertise – this thread is much richer and more useful because of both of you!
Thanks to everyone for the answer.
We are aware of the full operability of using Copilot, which is enabled by MS cloud services, and we are also aware of the problems that may arise due to the use of the # character, which is interpreted by various programs for other purposes.
Regardless, we have already reported the bug to MS support. Namely, the use of the # character in file names is not prohibited by MS, unlike some other characters or words (COM, a dot at the end of the name, a space at the end of the name, etc.).
In the early days of SkyDrive/OneDrive, the # in the file name also caused some interesting errors.
This looks like a genuine bug where Excel Copilot misinterprets the “#” character in local filenames—likely a parsing issue—since the same file works after renaming or when stored on OneDrive.
You’ve spotted a really interesting pattern! It’s totally understandable that you’d be confused—the error message is misleading, and the behavior definitely looks like a bug at first glance. Let me walk you through what's happening and, more importantly, how to get Copilot working smoothly for you.
Microsoft recommends using Copilot in Excel with files saved to OneDrive or SharePoint and AutoSave turned on, because that is where Copilot provides its most complete experience. However, local .xlsx files can also work with Copilot, so the fact that your file works after removing # strongly suggests a filename-parsing bug rather than an unsupported file type.
So why does the # character cause trouble locally?
Think of the # like a bookmark in a web address—it tells your browser to jump to a specific spot on a page. When Copilot looks at your local file path (for example, C:\Reports\Report #1.xlsx), it gets confused and treats everything after the # as a web bookmark instead of part of the actual filename. That breaks the path, so Copilot can't "find" your file properly and throws that confusing "unsupported file type" message.
Other symbols like % or & don't have this special "bookmark" meaning, which is why they work just fine.
Your best, most reliable solution
Since cloud storage gives Copilot the smoothest experience, your safest option is to save or move your workbook to OneDrive or SharePoint. Once it's there, just make sure AutoSave is switched on. When you open it from the cloud, Copilot should work perfectly—even if the # stays in the filename.
If you need to keep the file on your computer
You can simply rename the file to remove the #—for example, change Report #1.xlsx to Report - 1.xlsx or Report_1.xlsx. As you've already seen, this makes Copilot work again. Since this is a bug in the filename handling, renaming is a solid workaround that should keep working for you.
Should you report it to Microsoft?
Yes, please do! Your observation is valuable because it isolates the problem so precisely. You can go to Excel > Help > Feedback > Report a problem and share what you found. Mention that the same .xlsx file works locally without the #, works on OneDrive with the #, and that the error message is misleading. That kind of clear, reproducible case is exactly what helps Microsoft engineers track down and fix bugs.
My answers are voluntary and without guarantee!
Hope this will help you.
Thanks for the answer. We also have a very similar opinion regarding the confusion that can be caused by using the # character, which is interpreted by different programs for other purposes.
Regardless, we have already reported the bug to MS support. Namely, the use of the # character in file names is not prohibited by MS, unlike some other characters or words (COM, a dot at the end of a name, a space at the end of a name, etc.).
Your test shows a filename-parsing problem, but it is outside Copilot in Excel's documented local-file support boundary. Microsoft states that Copilot in Excel is supported only for .xlsx, .xlsb, or .xlsm workbooks saved to OneDrive or Microsoft 365 SharePoint with AutoSave enabled. That explains why the same workbook works on OneDrive, although the “file type” message is misleading. The supported workaround is to save the workbook to OneDrive or SharePoint, confirm AutoSave is on, and retain a modern format. If local storage is mandatory, Microsoft does not document a setting that enables Copilot there; removing # is only an observed workaround and may not remain reliable. Because # works in the cloud copy, report the local-path behavior through Excel's Help > Feedback. Include the Excel version, update channel, exact filename, storage path type, and an error screenshot so the product team can investigate.
