SharePointVault ~/gotchas/search ⌕ Search 404 pages, error messages, scripts…Ctrl K ★ Star
M↓ README.mdM↓ md-is-fulltext-indexed-despite-the-docs.md
sharepoint-vault›gotchas›search›md-is-fulltext-indexed-despite-the-docs.mdhistoryedit on GitHub
● GOTCHAsearch· 2 min read

Don't trust the parsed-file-types table: SharePoint Online full-text indexes .md

applies to: SharePoint Onlinereviewed: 2026-07-16#search#files#markdown#documentation

The official parsed-file-types table omits .md, but live SharePoint Online full-text indexes Markdown bodies anyway — treat .md as fully searchable, and run a two-minute live probe before you architect around any capability table.

Oficiální tabulka parsovaných formátů .md neuvádí, ale živý SharePoint Online těla Markdownu stejně plnotextově indexuje – ber .md jako plně prohledávatelný a než na nějaké tabulce schopností postavíš návrh, ověř to dvouminutovou živou zkouškou.

Symptom

You design a knowledge base or RAG architecture around the assumption that Markdown bodies are invisible to SharePoint Search, because the official table of default crawled extensions and parsed file types doesn't list .md anywhere — the Text handler covers .txt/.csv, the HTML handler covers .aspx/.html, and Markdown appears in neither. Docs read, conclusion drawn, mitigations planned.

Then a two-minute live test contradicts the whole thing.

Cause

The table is stale for SharePoint Online. Live SPO parses Markdown bodies just fine. Verified July 2026 on a production tenant: upload a .md file whose body (not filename) contains a unique word, wait about a minute, then hit the classic search endpoint —

GET https://contoso.sharepoint.com/sites/kb/_api/search/query
      ?querytext='dandelion filetype:md'
Accept: application/json;odata=nometadata
odata-version: 3.0

The file comes back, and the give-away is HitHighlightedSummary:

"summary": "<ddd/><c0>dandelion</c0>.<ddd/>"

The highlight is taken from the body — genuine content indexing, not a filename or metadata match. Both the modern library search (?q= / Microsoft Search) and the classic REST endpoint agree.

Fix

  • Treat .md as a first-class, fully searchable format in SharePoint Online.
  • The meta-fix: when an official capability table is load-bearing for your design, spend two minutes on a live probe before you architect around it. The recipe: unique word in the body, upload, query word filetype:xyz, and check that HitHighlightedSummary highlights the word — that last part is what distinguishes body indexing from a name/metadata hit.

Notes

  • The table still matters where it was born: SharePoint Server, where the handler list is real and extensible via iFilters. SPO evolves ahead of its own documentation.
  • Tested on one production SPO tenant (July 2026), indexed within ~a minute of upload. If this behavior is load-bearing for you, re-run the probe on your tenant — it costs two minutes.
  • Filename, Title and metadata columns are indexed regardless of format — that part was never in question.
  • Consequence for AI/RAG pipelines: with bodies indexed, Markdown wins the machine-channel comparison outright — clean 1:1 text extraction and full discovery. See choosing a knowledge format for RAG.
Was this helpful?ask or add your experience on GitHub →
Saved you an hour? A star on GitHub helps other SharePoint people find the vault.★ Star on GitHub
last reviewed: 2026-07-16last updated: 2026-09-24historyedit on GitHubview source