How to View Version History in SharePoint
Version history is the audit trail of every file. Knowing how to read it gives you confidence in what changed, when, and by whom.
What it is
Every time someone saves a file in SharePoint or OneDrive, the system records a new version. The version list shows the version number, date and time, author, and (if added) a check-in comment. You can open any version to see what the file looked like at that point, restore it, or compare it to the current version.
For controlled documents, version history is essential — it’s your audit trail. Auditors will ask ‘who approved this on what date?’ and version history (combined with check-in comments and approval records) is how you answer. Even for everyday work, version history is your safety net: you can always recover, always check what changed, always understand the file’s evolution.
The quality of version history is entirely shaped by how people use the system. Files saved without comments produce useless history. Files with meaningful check-in comments produce a real audit trail. This is why ‘always add a check-in comment’ isn’t just a tip — it’s the difference between version history that works and version history that’s there in name only.
When to use this
- When you need to audit who changed what and when.
- When you’re investigating an issue and need to understand a file’s history.
- When you want to find a specific change and possibly restore it.
- When you’re doing a quarterly review of a controlled document set.
How to do it
- Open the SharePoint library or OneDrive folder.
- Select the file (don’t open it yet).
- Click More options and select Version history.
- Review the list: version number, date, author, comments.
- Hover over a version to see a preview, or click to open in read mode.
- Use comments to understand what each version contained.
- Restore, copy, or just review — version history doesn’t change the current file.
Best practices
- Turn on versioning in every important library. Default settings often only keep major versions; consider enabling minor versions for active drafts.
- Insist on check-in comments. Without them, version history is just a list of dates.
- Use version history before recreating content. ‘I’ll start over’ is almost always the wrong answer.
- For audit, export version metadata. If your auditor wants a record, screenshot or export the version history table.
Common mistakes
- Disabling versioning to save storage. Storage is cheap; data loss is expensive.
- Saving ‘final v2’ files instead of using versioning. Defeats the purpose. Save in place, let SharePoint handle versions.
- Not training users to add check-in comments. Without comments, version history exists but is unusable.
The SharePoint Essentials System is the most comprehensive end-user guide in the range. 7 modules, 35 slides covering navigation, libraries, views, lists, metadata, permissions, and decision trees — updated for the new 2026 SharePoint App Bar.
Get the Essentials System — $37 →FAQ
How do I view version history in SharePoint?
Right-click the file in the library, choose Version history. The pane shows every saved version with date, time, editor, and any check-in comment. Click any version to open it (read-only). Click the dropdown next to a version to restore or delete it.
Why does SharePoint create so many versions of my file?
AutoSave creates a new version every time you save (and AutoSave saves frequently). For collaborative Office files, each round of edits creates new versions. This is the safety net that makes ‘oh no I overwrote it’ impossible — but it does generate many versions. Set version limits if storage is a concern.
Can I see who edited a SharePoint file and when?
Yes — Version History shows the editor’s name and timestamp for every version. For file-level audit (who opened, who downloaded), use the Microsoft Purview audit log instead — that captures every action, not just save events.
Are SharePoint versions visible to all editors?
Yes — anyone with edit access to the file can see version history. Read-only users can usually see versions but can’t restore them. This visibility is a feature, not a bug: it means the team has a shared, auditable record of how the document evolved.