Sharepoint Graph API file download URL bug, file name contains #

Question

We are encountering an issue with the Microsoft Graph API when downloading files from SharePoint using the /drives/{drive-id}/items/{item-id}/content endpoint.

Issue Summary

When a SharePoint file's name contains a # character, downloading the file via Graph using the item ID fails. The request still resolves to the correct item ID, but the /content endpoint returns a response that surfaces as "no content found" in our application. The exact same download call succeeds immediately after renaming the file to remove the # character.

Key Points

We are downloading files by item ID, not by path.
The download URL remains identical before and after the rename.
The itemId does not change between renaming the file to include or exclude #.

Metadata retrieval via:

GET /drives/{drive-id}/items/{item-id}works correctly in all cases, even when the name contains #.
Only the /content endpoint fails when the file name contains #.
As soon as the file is renamed to remove the #, the same /content request succeeds with no other changes.

Expected Behavior

Per Microsoft Graph DriveItem documentation, downloading by item ID should not be affected by the file's name, as the name is metadata and not part of the request URL.

Actual Behavior

GET /drives/{drive-id}/items/{item-id} → Succeeds
GET /drives/{drive-id}/items/{item-id}/content (with # in filename) → Fails with "no content found"
The same /content URL works immediately after removing # from the filename.

Request

Could someone confirm whether this is a known issue or a regression in the SharePoint/Graph integration? If not known, please advise on a workaround.

Answer 1

Hi @Brandon Worgull 

Thank you for posting your question in the Microsoft Q&A forum. 

After testing, I was able to successfully download a PDF file that contains a # character in its filename. However, when I try the same with Microsoft Office files such as .docx, .xlsx, or .pptx, the response begins with PK.  This confirms that the file content is being returned correctly on my side. The no content found message you mentioned does not appear when I test the download using Postman. 

I’ve done some research but haven’t found any reports or documentation that mention this issue. Could you please share the results of your testing on your side?

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".   

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.