How much space SharePoint versions really use

There’s a belief I’ve heard in various forms for years: SharePoint uses shredded storage, so it only keeps the differences between versions. It sounds reasonable, it rests on a real technology, and it leads to the conclusion that version history is essentially free in storage terms.

It isn’t. And because this is a claim that can be measured, we measured it.

This article isn’t an opinion. It’s a record of measurements taken on a live Microsoft 365 tenant, backed by quotations from Microsoft’s own documentation. Every number below can be reproduced in your own environment — the method is given, queries included.

What exactly is being claimed

The myth has two parts, and it’s worth separating them, because one of them is true:

1. “SharePoint uses shredded storage.” True — it is a real mechanism, introduced by Microsoft in SharePoint Server 2013.
2. “So versions only take up the difference from the previous version.” False, at least in the only sense a customer can observe and pay for: how it counts against the quota.

The gap between those two sentences is the heart of the misunderstanding, and we’ll come back to it in its own section.

Method

Measured on 2 September 2026 on a production Microsoft 365 tenant (SharePoint Online), on a demo site with a document library in its default configuration: versioning on, minor versions off, a limit of 500 major versions.

EnableVersioning: true
EnableMinorVersions: false
MajorVersionLimit: 500

The data is read through the SharePoint REST API, which returns the size of each version separately:

/_api/web/GetFileByServerRelativeUrl('<path>')/Versions?$select=VersionLabel,Size

Microsoft’s documentation for the version storage usage report describes the Size column unambiguously as “The size of the version in bytes”. It is not an estimate or a derived figure — it is the size the service records for that version.

We ran three independent measurements: an observation on a real document, a controlled experiment, and a completeness check.

Measurement 1: a real document with three versions

A Word document created and edited the ordinary way over a period of several months.

Version	Created	Size
1.0	18 Apr 2026	33,485 B
2.0	28 Aug 2026	40,606 B
3.0 (current)	2 Sep 2026	40,728 B
Total		114,819 B

The current file is 40,728 bytes. Its history adds a further 74,091 bytes. Together that is 2.82 times the size of the file you actually see in the library.

Look at the second row more closely, because it is the most telling. The difference between version 2.0 and version 3.0 is 122 bytes. If deltas were being stored, version 2.0 would cost a few hundred bytes. It is recorded at 40,606 bytes — essentially the full size of the document.

Measurement 2: a controlled experiment where not a single byte of content changed

Observing a real document has a weakness: the content did change between versions, so someone could object that a substantial part of the file was rewritten. Hence the second experiment, designed to rule that objection out entirely.

The procedure:

1. We uploaded a text file of exactly 1,048,576 B (1 MiB) to the library.
2. Three times in succession we changed metadata only — the value of the Title column, via REST. The binary content of the file was left untouched.
3. After each step we read back the sizes of all versions.

The result:

Step	Current version	Historical versions	Total
After upload	1.0 (1,048,576 B)	–	1.00 MB
After metadata change 1	2.0 (1,048,576 B)	1.0 = 1,048,576 B	2.00 MB
After metadata change 2	3.0 (1,048,576 B)	1.0, 2.0	3.00 MB
After metadata change 3	4.0 (1,048,576 B)	1.0, 2.0, 3.0	4.00 MB

Three edits that changed no content whatsoever quadrupled the space the document occupies. The increment per change was exactly 1,048,576 bytes each time — the full size of the file.

This is also the answer to the question I’m asked more often than any other: yes, a bulk metadata update — filling in a column from Excel, reclassifying a library, running a script across thousands of files — creates a new version on every document it touches, and every one of them counts at full size.

Measurement 3: is a historical version a complete file?

One last possible objection: what if the reported size is an accounting fiction and there is no full copy physically present?

We downloaded the content of historical version 1.0 directly:

/_api/web/GetFileByServerRelativeUrl('<path>')/Versions(<id>)/$value

1,048,576 bytes transferred. An exact match with the reported size. A historical version therefore behaves as a complete, independently downloadable file, not as an increment that has to be reconstructed from something else.

The test file was removed after the measurement, recycle bin included.

Where the myth came from, and why it is half true

Shredded storage really does exist. And there is a Microsoft document that mentions it in exactly the context of version sizes — Knowledge Base article KB 3038333. It describes a scenario strikingly similar to our second measurement: a 100 MB file, a change to metadata only, and a resulting reported size of 200 MB.

Microsoft’s comment on it:

“This behavior is by design. SharePoint Server 2013 uses SQL Server Shredded Storage to improve data transfer performance and reduce storage utilization. But the SharePoint quota component has no direct relationship to how SQL Server stores it physical data. Therefore, the quota component can’t report on the space that’s used on SQL Server physical storage.”

The whole contradiction sits in that one quotation. Shredded storage is a mechanism inside SQL Server. The quota component has no direct relationship to it and cannot report on physical SQL storage. That sentence is often cited as proof that “it actually takes up less” — but it says something different and considerably less comfortable: the quota knows nothing about physical storage and counts full sizes.

Two things deserve honesty here:

• The article quoted concerns SharePoint Server 2013, an on-premises product running on SQL Server. It cannot be transferred mechanically to SharePoint Online — SPO stores content differently, and Microsoft publishes no details of its internal arrangement.
• How much space your versions physically occupy in Microsoft’s datacentre cannot be measured by anyone outside Microsoft. And for you it has no practical significance.

One number does have significance: the one counted against your quota. And by both our measurement and the documentation, that is the full size of every version.

Indirect evidence from the documentation

There is one more argument, visible to anyone reading the documentation, that confirms the same thing from the other direction.

In 2024 Microsoft introduced automatic version history limits, and the storage planning guidance describes them like this:

“Under automatic settings intermittent older versions are trimmed over time, resulting in 96% version storage reduction in six months period compared to count limits.”

And a little further on, in a different example, “~94% reduction in version storage used compared to applying count limits only”.

Those figures make sense only if each version occupies space proportional to the size of the file. If deltas were being stored, trimming some of the intermediate versions could not possibly produce a saving of that magnitude — there is nothing to save when there is barely anything there. Microsoft did not introduce automatic limits because versions are cheap.

What to do about it in practice

Versioning is one of SharePoint’s most useful features, and “turn it off” would be bad advice. The aim is to pay for it deliberately.

Turn on automatic version history limits. Microsoft recommends them as the default choice, and the principle is sound: the recovery value of an old version declines over time. The algorithm is documented and worth knowing, because it tells you what will still be recoverable:

• all versions within the 500 limit during the first 30 days,
• hourly versions between day 30 and day 60,
• daily versions between day 60 and day 180,
• weekly versions beyond 180 days, until the 500 ceiling is reached.

Run a “what-if” analysis before you change anything. SharePoint can generate a version storage usage report for a site or library and model the effect of a limit before you apply it. It’s worth the wait — on large sites the report takes days to complete, but you get real numbers instead of a guess.

Trimming existing versions is irreversible. Versions removed by a limit or by a scheduled job bypass the recycle bin and cannot be restored from it. A version a user deletes by hand, by contrast, does go to the recycle bin — and holds the space until the bin is emptied.

Expect exceptions. For content under a retention policy or on eDiscovery hold, version limits are ignored for as long as the exception lasts. For documents marked as records, version deletion is blocked altogether. Anyone assuming a limit will solve everything is in for a surprise.

Watch bulk metadata updates. As the second measurement showed, they are the cheapest way to inflate your storage without adding a single useful word. Before a migration script or a mass reclassification, it is worth considering whether versioning needs to stay on throughout.

To put it in everyday terms: a 5 MB presentation that a team edits two hundred times over a year holds roughly a gigabyte under a 500-version limit. One file.

The limits of this measurement

For the conclusion to be honest, it has to include what we did not prove:

• We measured the sizes reported by the service, not the blocks physically occupied in Microsoft’s storage. Those cannot be measured from outside, and Microsoft does not publish them.
• The StorageMetrics interface, which we wanted to use to cross-check the figures at library level, returned zeros on the tenant tested — so that line of verification was not available to us.
• A site’s aggregate storage usage updates with a delay of, per the documentation, up to 48 hours. Measuring the difference on the quota immediately is therefore not a reliable method, and we deliberately did not rely on it.
• Measured on one tenant, in one library, in the default configuration (500 major versions, minor versions off).

What is proven, on the other hand: the number SharePoint records for each version — the number the quota is built on — equals the full size of the file, and a historical version is an independently downloadable whole. For storage decisions, that is the relevant quantity.

What to take away

1. No, versions are not deltas. For quota purposes each version counts at the full size of the file. A document with three versions occupies roughly three times what the Size column shows.
2. Even a metadata-only change isn’t free. We measured an increment of exactly the full file size for every such change. Bulk column edits are an expensive operation in storage terms.
3. Shredded storage is about something else. It is a mechanism inside SQL Server in on-premises SharePoint, and Microsoft itself writes that the quota component has no direct relationship to it. As an argument that “versions are cheap”, it does not stand up.
4. There is a solution, and it’s documented. Automatic version history limits, the usage report, “what-if” analysis and trimming. Microsoft’s own figure is a saving of 94 to 96 per cent compared with count limits alone.

---

At EP365 we handle SharePoint storage and governance as part of an environment audit and a governance design — including what the history you don’t know about is costing you. If your quota is growing faster than makes sense, drop us a line and we’ll go through it over your specific tenant.

In the next instalment we’ll look at what happens to content at the end of its life — retention, archiving, and why lifecycle decides whether your AI answers from valid documents.