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.
2 Replies
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.
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.
