| Capability | Supported in SharePoint Online / OneDrive | Notes |
|---|---|---|
| Browser preview | Yes | Side-by-side raw and rendered view, available since mid-April 2026 |
| Browser editing | Yes | Same side-by-side editor, saves to the library like any Office file |
| Real-time co-authoring | Yes | Added under MC1261592, rolling out from late July into August 2026 |
| Autosave | Yes | No manual save step once co-authoring is enabled for the file |
| Inline comments | Yes | Anchored to a line or block, same comment pane as Word and Excel |
| @mention notifications | Yes | Delivered through the same notification pipeline as other Office files |
| Version history | Yes | Standard SharePoint library versioning applies, no special-casing for .md |
| Sensitivity labels | Yes | Purview labels apply the same as for other supported file types |
| Rendered diagrams (Mermaid, PlantUML) | No | Raw fenced code blocks render as plain text, not as diagrams |
| Custom CSS or HTML embeds | No | Sanitised on render for security; embedded script and style tags are stripped |
| Offline editing via sync client | No | Files sync to disk normally but co-authoring and comments require the browser editor |
Markdown files inherit the same permission, retention, and versioning rules as every other file type in a SharePoint library. There is no separate governance track for .md content.
What changed and what stayed the same
Viewing and basic browser editing for Markdown files have existed in SharePoint Online and OneDrive since mid-April 2026. What changed in late July 2026 is the collaboration layer on top: multiple people can now hold the same .md file open at once, see each other's edits land without a save button, and leave comments tied to a specific paragraph. Before this change, a second person opening a Markdown file someone else was already editing would either get a stale copy or a lock message, exactly the friction that co-authoring in Word solved years earlier for document files.
What has not changed is the storage and permission model underneath. A Markdown file in a document library still counts toward the library's storage quota, still inherits the library's permission scope unless broken explicitly, and still keeps a version for every save under whatever versioning limit the library enforces. Admins sometimes assume a newly collaborative file type plays by different rules. Markdown does not; the quota, permission, and version behaviour is identical to any other file in the same library.
Where this shows up in admin workflows
Two places matter most for day-to-day administration. First, storage reporting: a project library that suddenly accumulates dozens of actively edited README.md and runbook.md files behaves like any other active library for storage purposes, so it will show up in a normal storage consumption report without any special filtering. Second, version accumulation: because co-authoring triggers frequent autosaves, a heavily edited Markdown file can accumulate version history faster than a document edited manually with occasional saves. The same version trimming guidance that applies to Office documents applies here too.