VS Code does not ship a built-in PDF to Markdown converter, so the reliable path is to first turn the PDF into a .docx file in Word or another compatible editor, then feed that .docx into a local, browser-based DOCX to Markdown Converter that never leaves your device. The browser tool reads the Office Open XML package inside the .docx, extracts the main document structure, and emits a downloadable .md file you can open directly in VS Code for an editorial pass. Because every byte stays on your machine, the workflow is well suited to drafts, internal reports, and notes that you would rather not upload to a third party. The resulting Markdown is structural rather than visual: explicit Word headings become Markdown headings, ordinary paragraphs stay as paragraphs, and simple rectangular tables become pipe tables, while custom fonts, page numbers, columns, images, tracked changes, and complex styles are deliberately left out instead of being guessed at. Open the resulting file in VS Code to confirm headings, links, lists, and table headers before publishing.
Why VS Code itself can't open a PDF as Markdown
VS Code is a code editor with strong Markdown support for files that already exist on disk, but it does not include a rendering engine for arbitrary PDF page content. Open a .pdf directly and you see the raw PDF preview, not editable Markdown. Extensions can wrap a Markdown preview around text the user provides, yet none of them can reconstruct a Word-style heading hierarchy, a rectangular table grid, or a paragraph of body text from inside the PDF object stream by themselves. The reliable shape of the problem is therefore a two-step pass: produce a structured, editable intermediate file from the PDF, then convert that intermediate into Markdown locally.
The most common intermediate is .docx, because Word and several office suites can open a PDF and re-save it as a Word document. That re-save is lossy in its own right: shapes, scanned text without an OCR layer, custom fonts, and exact page breaks are not carried over. What survives is the structural skeleton that the next step actually needs, namely paragraph boundaries, explicit heading styles where the document author used the styles gallery, and rectangular table grids. With that skeleton in hand, a local converter can produce Markdown that is closer to the original draft than any tool that guesses structure from font size or bold weight.
What the local DOCX to Markdown Converter actually does
The DOCX to Markdown Converter takes a single .docx Word document and turns it into a practical Markdown draft inside your browser. It reads the Office Open XML package with the JSZip loader, parses the main document XML through the standard DOMParser, and maps explicit Word Heading 1 through Heading 6 paragraph styles to the matching Markdown levels from # through ######. Ordinary paragraphs stay as ordinary paragraphs, and simple rectangular tables are emitted as Markdown pipe tables with the first row used as the table header. Markdown-sensitive characters inside cells are escaped so that pipes inside a cell do not break the table syntax.
The tool deliberately refuses to invent structure it cannot see. It does not guess heading levels from font size or bold text, so a custom-styled title that never used the Heading 1 style remains a normal paragraph instead of being silently promoted. Merged cells, nested tables, uneven rows, and complex list numbering fall back to readable tab-separated text instead of being forced into a Markdown table that would misrepresent the data. Tabs and line breaks are preserved visibly. Layout, images, comments, tracked changes, fields, citations, text boxes, custom fonts, and theme styles are explicitly outside the contract; the converter is structural, not visual.
Convert PDF to Markdown in VS Code: the full sequence
The full sequence has six concrete steps and keeps the original PDF on your device until you choose to send it to a converter.
- Open the PDF in Microsoft Word, Google Docs, or another office suite that supports PDF import, then use "Save As" to export it as a .docx file. Inspect the headings in the styles pane and confirm that section titles use the built-in Heading 1 through Heading 6 styles; any title that only appears bold will not turn into a Markdown heading in step 3.
- Open the DOCX to Markdown Converter in your browser and choose the .docx file from your device. The browser validates the package size, ZIP directory shape, entry count, and declared expanded size before loading it locally; damaged, password-protected, unsupported, or oversized files are rejected clearly.
- Wait for the local preview to populate. The preview is read-only and shows the Markdown approximation the converter has produced from the Word document, including the heading levels and any pipe tables that the rectangular grid could represent.
- Download the generated .md file to a folder you can reach from VS Code, such as the repository where the Markdown will live. The file lands as a plain text .md file, which is the form VS Code treats as Markdown by file association.
- Open the downloaded .md file in VS Code. Use the Markdown preview side panel to compare the rendered headings, paragraphs, lists, and tables against the original Word document and flag anything that needs an editorial fix.
- Make the small editorial pass that every document conversion expects: confirm that each heading is truly a section heading, repair links or lists that depended on Word-specific behavior, check table headers, and remove any temporary formatting that does not make sense in the destination.
At the end, the original PDF has not been uploaded anywhere; only the .docx you produced locally and the .md file the converter produced locally exist on disk, and both can be deleted without touching a remote service.
What carries over to Markdown, and what doesn't
Word's feature set is much richer than Markdown's, so a converter can only carry over what Markdown can express. The table below lists the Word elements that the DOCX to Markdown Converter recognizes and what each one becomes in the output.
| Word element | Markdown output |
|---|---|
| Explicit Heading 1 through Heading 6 paragraph styles | Matching Markdown heading level from # through ###### |
| Ordinary body paragraph | Ordinary paragraph text |
| Simple rectangular table | Markdown pipe table, first row as header, pipes inside cells escaped |
| Tab characters and line breaks | Preserved visibly as plain text |
| Custom paragraph style, bold or large font used as a fake heading | Stays as a plain paragraph; the tool does not promote by appearance |
| Merged, nested, or uneven tables | Falls back to tab-separated text rather than a misleading table |
| Images, shapes, charts, comments, tracked changes, fields, citations, text boxes, theme styles | Not represented in the output; not silently invented |
Reading the table first establishes what is faithful, and what the editorial pass in VS Code will have to handle by hand.
Tidying the draft inside VS Code
Markdown is source content, so a short editorial pass after any document conversion is expected, not a sign that the converter failed. Use VS Code's split Markdown view to compare the rendered preview against the original Word file. Confirm that section breaks became heading breaks, that lists still read as lists, and that table headers describe the columns accurately. VS Code's outline view, powered by the Markdown headings, is a quick way to spot any heading that is actually a sub-heading or vice versa; correcting one character fixes the entire outline and the table of contents that downstream tools build from it.
If a heading shows up as body text, the original document almost certainly used a custom style or bold text instead of the Heading 1 through Heading 6 styles. Re-exporting the .docx from Word after applying the correct paragraph style, then re-running the converter, fixes that case without touching the .md file by hand. If a table reads as tab-separated text, the original probably had merged cells, nested tables, or uneven rows; either simplify the table in Word first or accept the tab-separated fallback as the authoritative version.
When to pick a separate tool instead
The local converter is the right starting point when the destination is a documentation site, repository, note app, CMS editor, or static-site workflow where plain Markdown is easier to review and version than a binary Word file. It is the wrong starting point for pure text extraction without any Markdown formatting at all: in that case, the DOCX to Text Converter produces clean plain text from the same .docx. It is also the wrong tool for harvesting document links or pulling out embedded images; dedicated Word hyperlink and image-extraction tools handle those single-purpose jobs without making broad fidelity promises.
Keeping those tasks separate prevents a single converter from silently promising more than it can deliver. A local, structural Markdown draft plus a quick editorial review in the Markdown editor is the realistic target, and for that target the DOCX to Markdown Converter gives a clean starting point without uploading the source.
If you're weighing options, Emoji Copy and Paste Explained: From Code to Clipboard covers this in detail.
If you're weighing options, Special Characters: Command Line vs Online Copy and Paste covers this in detail.