Why heading-based splits beat fixed-size splits
A fixed-size chunker knows nothing about meaning: it will cut a paragraph in half, separate a table from its caption, and merge the end of one topic with the start of the next. Heading-based splitting uses the structure the document already declares. Each chunk starts where a section starts, so the text inside it stays about one thing. When a section is too long, split it at paragraph boundaries and prepend the heading path, never in the middle of a sentence.
What every chunk should carry
1) The heading path, such as Product Guide > Installation > Docker, so a retrieved answer is interpretable without the surrounding document. 2) Complete tables and fenced code blocks - never split them; if a table exceeds the chunk budget, keep it whole and shrink the prose around it. 3) List items together with the sentence that introduces them. 4) A stable source reference, which is easy when the Markdown export carries YAML front matter with the original file name. 5) A token cap applied after assembly, so structure is never sacrificed to hit a size target.
Where conversion quality decides chunk quality
Chunking inherits every upstream defect: a flattened heading hierarchy removes the very boundaries you want to split on, a broken table grid yields fragments that no longer parse, and missing alt text strips images of their meaning. That is why the conversion step is the highest-leverage place in a RAG pipeline. MarkItDown Online keeps heading structure, tables, and links intact through PDF, Office, and HTML conversion, and the batch preview shows the heading tree before files reach the chunker. Typical conversions finish in 2-5 seconds per file. Questions: sapsap@qq.com.