Conversion is the beginning of a Markdown workflow, not the end. PDF extraction can recover words while still misrepresenting hierarchy, reading order, links, and document boundaries. A fluent paragraph is not proof that the structure is correct.
This checklist is designed for material that will be published, indexed, committed to a documentation repository, or passed to another system. For a disposable personal note, you can shorten it. For legal, medical, financial, or scientific content, add domain-specific review.
Preserve the source and record context
Keep the original PDF until the Markdown has passed review. Name the derived file so its relationship is clear, and record the conversion date and tool when provenance matters. If the source has a version number, include it in frontmatter or an adjacent note rather than relying on the file name alone.
Do not overwrite an earlier reviewed Markdown file with a new automated conversion. Use version control or a separate working copy so you can inspect changes. A later converter update may improve headings while accidentally changing numbers or links.
For confidential documents, store both source and derivative according to the same access policy. Converting to plain text does not remove sensitivity.
Fix headings by meaning
PDF heading detection often relies on font size, but typography and hierarchy are not identical. A large pull quote may become a heading, while a small all-caps section label may remain a paragraph. Review every Markdown heading in an outline view.
Use one H1 for the document title when the publishing system does not provide it separately. H2 headings should represent major sections, with H3 for subsections. Avoid skipping directly from H2 to H4. Do not choose heading levels for visual size; CSS controls appearance, while Markdown levels communicate structure to readers, search engines, and assistive technology.
Search for headings that contain page numbers, running headers, or incomplete sentences. These are often extraction artifacts.
Normalize paragraphs and line endings
Join visual line wraps into paragraphs. Ordinary prose should not contain a hard line break after every source line. At the same time, preserve deliberate boundaries between paragraphs, list items, addresses, poetry, and code.
Look for end-of-line hyphenation. A word split as docu- at the end of one line and ment at the start of the next should usually become document. Keep genuine compounds such as privacy-first. Automated replacement can help, but dictionaries do not cover names and technical terms, so sample the changes.
Remove repeated page headers, footers, and isolated page numbers. If page provenance is important, replace raw artifacts with consistent comments or structured page markers rather than leaving them inside sentences.
Rebuild lists deliberately
Confirm that each bullet is a separate item and continuation lines remain attached to the correct item. Nested lists need consistent indentation. A sequence of numbered paragraphs is not always a Markdown ordered list; legal clauses and figure references may need their original labels preserved as text.
Check numbering across page and column breaks. Markdown can automatically renumber list items when rendered, which may hide a missing or duplicated source number. For procedures where exact labels matter, retain explicit numbers and compare them with the PDF.
Task lists should use [ ] only when the source actually represents actionable state. Do not transform decorative boxes into unchecked tasks without context.
Verify emphasis, code, and quotes
Bold and italic inference depends on font metadata. Review emphasized warnings, defined terms, and citations against the source. Remove accidental emphasis that spans punctuation or entire paragraphs because a font switch was misread.
Inline code should represent code, commands, file names, or identifiers—not merely monospaced decoration. Code blocks need language fences only when the language is known. Preserve indentation-sensitive examples and compare every symbol; typographic quotes or dashes can break executable commands.
Blockquotes should be used for quoted material, not for arbitrary indentation. Add attribution if the source provides it.
Test links and references
Open every important link. PDF annotations can cover only part of the visible label, and extracted URLs may contain line breaks. Replace vague labels such as “click here” when you control the editorial content, but do not change quoted source wording without marking the edit.
Internal references such as “see page 14” may become invalid when the content moves to a web page. Replace them with section links if appropriate, or retain the page reference when the PDF remains the authoritative source. Footnotes need stable anchors and backlinks if the target renderer supports them.
Remove tracking parameters only when doing so does not change access or attribution. Do not guess a canonical URL for private or signed links.
Review tables, images, and omitted material
Render every table and compare high-risk cells. Count columns, confirm empty cells, and verify totals. If the structure is too complex for Markdown, use CSV, HTML, or a summarized representation rather than publishing a misleading grid. The PDF table guide provides a fuller decision process.
Text-layer converters may omit images entirely. Add placeholders and descriptive alt text for figures that are necessary to understand the document. Confirm that captions have not been detached or presented as ordinary paragraphs.
Equations, signatures, stamps, handwritten annotations, and marginal notes may also be absent. Record these omissions when they affect interpretation.
Run deterministic checks
A Markdown linter can catch malformed headings, inconsistent list indentation, duplicate headings, trailing whitespace, and broken fences. A link checker can find unreachable URLs, although authenticated and rate-limited links need careful interpretation. Spellcheck is useful after dehyphenation but should not silently replace names.
Use version control to inspect the cleanup diff. Search for numbers, currency values, dates, email addresses, and identifiers that changed. For a collection, automate checks for empty files, unusually short outputs, repeated headers, and missing titles.
Finally, render the document in the actual destination, not only a generic preview. GitHub, documentation frameworks, note applications, and static-site generators support different Markdown extensions.
Approve with a sampled comparison
Compare the first page, a random middle page, the hardest layout, and the final page with the source. For critical documents, review every page or use a second reviewer. Record unresolved limitations instead of hiding them.
A clean result has a meaningful heading outline, natural paragraphs, correct lists, verified links, appropriate table formats, documented omissions, and no accidental disclosure of sensitive metadata. Once those conditions are met, the Markdown can serve as a maintainable document rather than a raw extraction artifact.
