While reading a file from sharepoint using graph api endpoint, the size keeps on changing 5-6 bytes every time also the checksum for the file changes without any changes in the content or metadata

Question

Subject: SharePoint modifies DOCX customXml itemProps on upload without body change

Environment

• SharePoint: Online and Private Farm
• Clients: API-based upload; no user edits in Office during test
• File types: DOCX (Microsoft Word 2007+)

Issue summary

• Re-uploading an identical DOCX causes SharePoint to alter the OOXML package by changing only customXml item property parts, while the document body and main XML parts remain unchanged. This changes the file’s SHA-256. We’ve also observed that cTag did not change despite byte differences.

Steps to reproduce

1. Upload DOCX to library.
2. Re-upload the same DOCX (identical bytes, no edits).
3. Download both versions.
4. Compare before/after locally.

Expected

• SharePoint preserves the file bytes when the uploaded file is identical.

Actual

• File bytes differ due to changes in customXml itemProps files. No changes to body or core/app props.

Evidence (from local comparison)

• Files:
• BEFORE: 2006-10-01-Ascot-Partners-
• AFTER: 2006-10-01-Ascot-Partners-
• SHA-256:
• BEFORE: <PII Removed>
• AFTER: <PII Removed>
• Tree diff (only differences):
• customXml/itemProps1.xml (CRC, packed size changed)
• customXml/itemProps2.xml (CRC, packed size changed)
• customXml/itemProps3.xml (CRC, packed size changed)
• Unchanged (decompressed hash identical):
• word/document.xml, word/styles.xml, word/settings.xml, docProps/core.xml, docProps/app.xml
• zip metadata shows offsets and deflate sizes differ only for customXml itemProps

Questions

1. Is it expected for SharePoint to rewrite customXml/itemProps*.xml on upload even when the uploaded DOCX is byte-identical to the current version?
2. Which features drive this behavior (content types, property promotion/demotion, columns mapped to document properties, Office Online settings)?
3. How can we prevent SharePoint from modifying DOCX package parts like customXml/itemProps on upload?
4. Should cTag reflect these byte-level package changes? We’ve observed cases where bytes changed but cTag did not—please confirm expected behavior.
5. Is there any documented guidance or settings to keep DOCX package bytes stable across upload/re-upload scenarios?

Impact

• Our system uses streamed SHA-256 for integrity; package-only mutations (customXml itemProps) trigger false positives and unnecessary versioning. We seek a SharePoint-side configuration to avoid the package mutation entirely.

Answer 1

Hi Mahesh Sharma

Thank you for posting your question in the Microsoft Q&A forum.For this specific issue, I suggest you open a support ticket with our support team.

However, I will try to gather as much as information to help you.

Please correct me if my understanding is wrong.

Based on my research, the behavior you see is expected due to property promotion.

Property promotion is the process of extracting values of a document and writing those values to corresponding columns on the list or document library where the document is stored.

Document Property Promotion and Demotion | Microsoft Learn

cTag doesn’t always change is consistent with how Microsoft treats some changes as metadata level only or considers customXml modifications as "non-content" for cTag/eTag purposes. 

Currently, you cannot disable property promotion in SharePoint Online.

Unfortunately, I was unable to find any documents to keep DOCX package bytes stable across upload/re-upload.

I am sorry that I cannot assist you further, you can create a support ticket via Admin Center.

I hope the information I provided will be helpful to you.

---

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.