How to Convert PDF to Markdown Without Losing Structure

A PDF resume arrives in your inbox, but the source file is gone. Copying the content into an editor gives you a flattened block of text, broken bullets, scrambled columns, and tables that no longer line up. The practical argument here is simple: convert PDF to Markdown as a structure-recovery task, not a text-extraction task. The cost is that you give up instant visual fidelity and spend time validating the result, but that trade-off produces content you can edit, version, parse, and rebuild reliably.

Table of Contents

• Why a Clean PDF-to-Markdown Conversion Matters
• Structure survives only when you check it
• Converting Text-Based PDFs with Command-Line Tools
• When Pandoc needs help
• Handling Scanned PDFs and OCR Workflows
• Marker for layout-aware OCR
• Cleaning Up the Markdown After Conversion
• Repair headings and lists first
• Rebuild tables instead of trusting broken pipes
• Keep code and images portable
• Choosing the Right Conversion Route
• ATS-Friendly Conversion for Resumes
• Markdown patterns that hold up
• Quick Checklist and What to Do Next

Why a Clean PDF-to-Markdown Conversion Matters

A PDF preserves positions on a page. Markdown preserves relationships between pieces of content. Those formats solve different problems, and a conversion that keeps only visible words misses the part that makes the document useful.

A two-column resume may look perfectly clear to a human reader. A basic extractor can read the left column, jump to the right column, return to the next line on the left, and output one long sequence. The same failure appears with a sidebar, a skills matrix, a footer, or a multi-level list. Once that ordering is wrong, every downstream tool receives a distorted document.

Structure survives only when you check it

A useful Markdown conversion should recover:

• Heading hierarchy, such as # Resume and ## Experience
• Reading order, especially across columns and sidebars
• List nesting, with bullets and numbered items kept distinct
• Tables, where rows and columns still mean what they meant in the PDF
• Code and technical content, enclosed in fences or inline backticks
• Images and links, represented as usable Markdown references rather than opaque embedded data

Tools that advertise semantic blocks, table extraction, OCR fallback, and layout awareness are responding to this exact problem. A tool such as pdf2markdown.org describes mapping headings, lists, tables, code blocks, images, and links into structured output rather than dumping raw text.

The PDF standard itself is mature. Adobe released PDF in 1993, ISO published PDF 1.7 as ISO 32000-1:2008 in July 2008, and ISO published PDF 2.0 as ISO 32000-2:2020 in December 2020. That long history means converters are interpreting a format with decades of revisions and layout conventions, not a simple text container. The history of PDF provides the relevant specification timeline.

A clean conversion is successful only when the next tool can understand the document, not merely display the same words.

For resumes, the cost of a bad conversion is practical. A broken heading can make experience look like ordinary paragraph text. A flattened skills table can merge unrelated technologies. A scrambled two-column layout can make dates appear beside the wrong role. Our guide to why resume formatting breaks after PDF conversion covers the layout failure in more detail.

Converting Text-Based PDFs with Command-Line Tools

Start by determining whether the PDF contains selectable text. Try selecting a sentence and pasting it into a plain-text editor. If readable characters appear, treat the file as born-digital, meaning it was produced from a text-aware application such as Word, Google Docs, or LaTeX.

For a straightforward file, begin with Pandoc:

pandoc input.pdf -o output.md

Pandoc is useful for a quick draft, especially when the source has a linear reading order. Add media extraction when the PDF contains images:

pandoc input.pdf --extract-media=./media -o output.md

Long wrapped lines make diffs and manual inspection harder, so this option can help:

pandoc input.pdf --extract-media=./media --wrap=none -o output.md

When Pandoc needs help

Pandoc alone won't repair a PDF with weak structural metadata. For those files, extract positioned text first:

pdftotext -layout input.pdf output.txt

The -layout flag attempts to retain spatial placement, which can preserve reading order better than a plain text dump. You can then inspect the result and convert it as Markdown:

pandoc -f markdown -t markdown output.txt -o clean.md

This doesn't magically reconstruct every heading or table. It gives you a more inspectable intermediate file, which is often preferable to trusting an apparently polished but structurally wrong output.

A Node.js option, pdf2md, is built on Mozilla's PDF.js and can handle two-column layouts and footnotes more gracefully in suitable documents. A practical comparison workflow is:

1. Run Pandoc and inspect headings, lists, and column order.
2. Run pdf2md on the same source when the first result interleaves content.
3. Diff both Markdown files.
4. Keep the version with the better reading order, then repair the remaining structure manually.

For a benchmark-oriented view, an independent comparison of 10 PDF-to-Markdown tools found a clear trade-off. Marker scored 44/50 overall, including 8/9 on headings, 8/9 on tables, 10/10 on equations, 9/9 on OCR, and 9/9 on reading order, while processing a 30-page document in 1.4 seconds on GPU. Text-only pipelines such as PyMuPDF and Pandoc combined with pdftotext were faster but scored 10/50 and 8/50, respectively. The lesson is more useful than the ranking: speed doesn't compensate for lost structure.

Handling Scanned PDFs and OCR Workflows

A scanned PDF contains page images, even though the images are wrapped in a PDF file. pdftotext, Pandoc, and similar extractors can't recover words that aren't present as a text layer. The workflow must therefore run OCR first, then perform Markdown cleanup.

For a single-column image, Tesseract is a practical starting point:

tesseract scan.png output -l eng --psm 6

Other page segmentation modes are useful in different layouts:

• Single-column variable text: --psm 4
• Automatic page segmentation: --psm 3
• Mixed languages: use the relevant language packs, such as -l eng+fra

For multiple page images, process each file and collect the text:

for f in pages/*.png; do tesseract "$f" "${f%.png}" -l eng; done

OCR accuracy depends heavily on the source image. Low-resolution scans, skewed pages, rotation, compression artifacts, and unusual fonts create predictable errors. Preprocess difficult pages with unpaper, or use ImageMagick to deskew and improve contrast before sending them to Tesseract.

Marker for layout-aware OCR

Marker is a heavier local option that combines layout detection, OCR, and table extraction:

marker_single scan.pdf --output_format markdown

Its output can preserve heading levels and richer document structure than a raw OCR transcript, but installation takes more work, and GPU hardware improves speed. Marker has been evaluated on olmocr-bench, a third-party set of 1,403 PDFs covering math, tables, multi-column layouts, scans, and difficult edge cases. Its balanced mode reached 76.0% overall accuracy and 83.5% on born-digital PDFs, according to the Marker project documentation.

Those figures don't remove the need for review. A benchmark measures a defined task, while your resume, invoice, or technical report has its own layout conventions. The recommended evaluation method is to run the converter at real worker concurrency, score Markdown per page with the benchmark checker, and review macro-average and digital-only results. For a personal document, the equivalent is simpler: inspect every heading, table, date, and list that matters.

Multilingual scans need special attention. Some browser tools work well for English but require external OCR or specialized rendering for Arabic, CJK, mixed-language, or other non-Latin content. A workflow that detects whether the source is born-digital or scanned, checks language support, and validates the output is safer than treating OCR as a single checkbox.

Cleaning Up the Markdown After Conversion

Raw output needs a deliberate cleanup pass. Extraction tools make educated guesses from coordinates, font sizes, glyphs, and image recognition. Those guesses are useful, but they aren't a substitute for checking the document's meaning.

Repair headings and lists first

A common heading failure looks like this:

**Experience**
Senior DevOps Engineer

Convert the standalone label into an actual heading:

## Experience

### Senior DevOps Engineer

The exact level depends on the surrounding hierarchy. Promote standalone bold lines when they clearly label a section, remove stray # prefixes introduced by extraction, and merge duplicate labels created by repeated page headers.

Lists need the same treatment. OCR may produce:

• Managed deployment pipelines
• Reduced manual release work

Normalize the bullets:

- Managed deployment pipelines
- Reduced manual release work

When OCR merges two entries into one paragraph, restore each item based on indentation, punctuation, and the original page. Don't preserve a bullet glyph merely because it looks familiar. Markdown readers and parsers work more consistently with -, *, or ordered markers.

Rebuild tables instead of trusting broken pipes

A clean pipe table is readable:

| Tool | Use |
|---|---|
| Docker | Containers |
| Terraform | Infrastructure |

A damaged conversion may look like this:

Tool Docker Terraform
Use Containers Infrastructure

When column boundaries are obvious, rebuild the pipe syntax. When the source uses merged cells, nested headers, or layout tables, a list of labeled rows may communicate the data more accurately than a misleading table.

The hardest structures are usually tables, formulas, headings, and reading order. A benchmark writeup on PDF Markdown retrieval and table fidelity reports downstream retrieval correctness ranging from 0.46 to 0.81 and table fidelity from 1.7/5 to 4.2/5 across conversion variants. Small extraction choices can materially change whether the output is useful.

Keep code and images portable

Fence code blocks and add a language tag:

```bash
pandoc input.pdf -o output.md

Escape backticks inside code when necessary, and normalize indentation so nested examples don't become ordinary paragraphs. Replace base64 image blobs with descriptive references:

```markdown

This keeps the Markdown reviewable and prevents enormous embedded strings from obscuring the content. Finally, search for repeated headers, footers, page numbers, broken hyphenation, empty lines, and links that point to the wrong destination.

Choosing the Right Conversion Route

No single converter wins on every PDF. The right choice depends on whether the file contains selectable text, whether tables matter, how much local setup is acceptable, and whether the final output is a resume rather than a general document.

Privacy is the deciding factor for sensitive files. Local tools keep processing in your environment, while online services require careful review of their data handling. Open-source tools offer control, but the setup burden and model dependencies are part of the cost.

For a resume, the destination matters as much as the extractor. Resumey.Pro accepts an existing resume as a PDF and automatically converts the imported content into clean, structured Markdown inside its editor. That route is practical when the goal is to recover resume content and continue editing it in a Markdown-first builder rather than maintain a generic document archive. Its Markdown-to-PDF workflow is also described in this guide to converting Markdown to PDF.

The decision rule is straightforward: use Pandoc for a quick text-PDF draft, Marker for local OCR and layout recovery, an online service for a difficult scan when privacy permits, and Resumey.Pro when the end goal is a parseable resume.

ATS-Friendly Conversion for Resumes

Resume conversion should prioritize reading order and semantic hierarchy, not pixel-level imitation. A designed PDF may use positioned text boxes, sidebars, columns, icons, and decorative elements to create a visual composition. Those devices can become separate text fragments when an ATS reads the file from top to bottom.

ATS parsers look for recognizable section labels and extract content as a sequence. A heading such as ## Experience gives the section a clear boundary. A dash-prefixed bullet gives each achievement a discrete entry. A two-column layout can instead linearize the contact block, skills, dates, and experience in an order that no human intended.

Markdown patterns that hold up

Use familiar labels and simple structures:

## Experience

### Site Reliability Engineer, Example Company

- Built deployment automation for production services
- Maintained observability dashboards and incident runbooks
- Partnered with security teams on access reviews

Keep these rules close at hand:

• Use standard headings: Prefer Experience, Education, Skills, and Certifications over decorative labels.
• Keep bullets explicit: Start each experience item with -, and avoid hiding several achievements in one paragraph.
• Limit tables: A simple pipe table can work for a skills matrix, but ordinary skills lists are safer and easier to parse.
• Remove visual containers: Strip text boxes, layout-only divs, floating labels, and decorative columns.
• Delete artifacts: Remove repeated headers, footers, page numbers, and image-based text.
• Preserve links plainly: Keep portfolio, GitHub, and LinkedIn URLs as readable Markdown links.

For practical guidance on submitting a resume file to an ATS workflow, this guide to how to upload a resume for ATS is a useful companion. The central technical rule remains the same: preserve the order in which a parser should read the content.

Rebuilding from cleaned Markdown is usually faster than forcing an ATS to understand a visually complex PDF. You keep the factual content, discard layout containers that carry no semantic value, and apply a controlled resume template afterward. For multilingual resumes, validate direction and script support separately. Right-to-left text, mixed-language lines, URLs, and technical tokens may need different rendering behavior, as documented in the Markdown editor changelog.

Quick Checklist and What to Do Next

Use this checklist on a real file:

1. Identify the source: Confirm whether the PDF is text-based or scanned.
2. Choose extraction: Run Pandoc or pdf2md for born-digital content.
3. Run OCR when needed: Route scans through Tesseract or Marker.
4. Remove artifacts: Strip page numbers, repeated headers, footers, and broken hyphenation.
5. Restore hierarchy: Use #, ##, and ### markers for document levels.
6. Normalize lists: Convert inconsistent glyphs into - or * bullets.
7. Repair tables: Use GitHub-Flavored Markdown pipes only when the columns remain meaningful.
8. Format technical content: Put inline code in backticks and fenced code in language-tagged blocks.
9. Validate the render: Check reading order, dates, headings, tables, links, and multilingual text.

The final bridge is simple. Paste the cleaned Markdown into Resumey.Pro's import field, review the rendered structure, and adjust the resume content without retyping the source document.

Upload your existing resume PDF to Resumey.Pro to auto-convert it into editable Markdown, then use the ATS-friendly templates and clone feature to maintain clean versions for different roles. Visit Resumey.Pro and turn the recovered structure into a polished, parsable resume.