Version History
Common Use Cases
- Accidental edit recovery: restore a document that was accidentally overwritten or corrupted by a co-author from any previous version
- Audit trail for regulated content: demonstrate who made what changes and when on compliance-sensitive documents such as contracts or policies
- Draft vs. published content management: use major/minor versioning to keep draft revisions visible only to editors, while the last approved major version is visible to readers
- Change history documentation: reference version history to understand the evolution of a technical specification or business process document over time
Benefits
- Automatic and invisible: every save creates a new version entry without user action
- Granular restore: restore any specific version with one click; SharePoint replaces the current file with the restored version and records the restore as a new version entry
- Version comparison for Word docs: SharePoint can open a tracked-changes comparison view between any two selected versions of a Word document
- Intelligent Versioning reduces storage cost: the Intelligent Versioning feature automatically thins older versions, keeping storage manageable without manual cleanup
- Metadata versioning for lists: every field change on a list item creates a new version, giving a complete audit trail of metadata edits across the item’s lifecycle
- Retention policy integration: Microsoft Purview retention policies can be applied to version history, ensuring versions are kept or deleted for the appropriate regulatory period
Details
- Feature Category: File Management
How It Works
- On by default: versioning is on by default in every new library and list, and each save creates a new numbered version automatically
- 500-version default: document libraries keep the last 500 major versions by default, and during co-authoring versions are captured periodically rather than on every keystroke
- Each version counts at full size: a 100 MB file with 10 versions consumes roughly 1 GB of quota
- Restoring does not erase history: the restored copy simply becomes the newest version on top of the stack
- List items version too: every field change on an item creates a new version, producing a complete metadata audit trail
- Optional draft versioning: minor (draft) versioning in libraries keeps drafts visible to editors while readers see only the last published major version
Limits and Nuances
- Configurable version count: library limits accept 100 to 50,000 major versions (the UI will not go below 100), set per library and tuned to each library’s activity level
- Automatic trimming by age: the organization-level Automatic setting trims versions by age with a built-in algorithm, Microsoft’s recommended balance of recovery and storage
- Manual limits can add expiry: a manual limit can combine a version count with an expiration period, for example 500 versions kept no more than 365 days
- New limits apply to new libraries only: existing libraries and existing versions are untouched until you run a separate trim job
- A hard 500 ceiling under Automatic: even under Automatic, SharePoint keeps no more than 500 versions of a file, so export anything you must keep forever
- Set limits before storage balloons: every version counts at full file size against the site quota, so set limits or Automatic before busy libraries eat storage
- Trimmed versions bypass the Recycle Bin: versions removed by a limit or trim job cannot be recovered; only versions a user deletes manually go to the Recycle Bin
- Not a backup, and retention wins: version history is not a backup (versions die with a permanently deleted file once the 93-day window passes), minor versioning keeps up to 511 drafts per major version, and retention policies or eDiscovery holds preserve held versions regardless of library limits
Common Questions About Version History
How many versions does SharePoint keep by default?
New document libraries in SharePoint Online store the last 500 major versions of each file out-of-the-box. Once a file passes that number, SharePoint deletes the oldest version to make room for the newest. Admins can raise the limit as high as 50,000 per library, lower it to 100, or switch the organization to the Automatic setting and let SharePoint manage version storage by age.
Does version history use up our storage quota?
Yes. Every version is counted at the full size of the file, so a 50 MB presentation with 20 versions consumes about 1 GB of the site’s quota. This is the main reason to set sensible version limits or use the newer Automatic setting, which trims older versions on an age-based schedule. Version storage reports in the admin center show exactly where the space is going.
How do I restore a previous version of a file?
Select the file in its library, open the menu, and choose Version history – you will see every saved version with date, author, and size. Restoring one replaces the current file, but nothing is lost: the restore itself is recorded as the newest version, so you can always step back again. For Word documents, SharePoint can even open a tracked-changes comparison between two versions.
What is the new Automatic version history setting?
Automatic is an organization, site, or library-level option where SharePoint trims versions using a built-in age-based algorithm instead of a fixed count – keeping more recent versions densely and thinning out older ones. Microsoft recommends it because it preserves realistic recovery points while controlling storage. It applies to newly created libraries; existing libraries keep their old limits until you run a trim job.
Can I get versions back after a file is deleted?
Within the safety window, yes – a deleted file goes to the Recycle Bin with its version history intact, and restoring the file restores its versions. After the 93-day Recycle Bin retention expires, the file and every version are permanently gone. Versions removed by version limits or trim jobs are different: those bypass the Recycle Bin entirely and cannot be recovered.
Is version history a substitute for backup?
No, and treating it as one is a common mistake. Version history protects against bad edits and overwrites, not against deletion – once a file is permanently removed, its versions go with it. For content with regulatory requirements, pair versioning with Microsoft Purview retention policies, which preserve versions for the required period even when library limits would otherwise trim them.