I'm Owen, an indie developer in Ho Chi Minh City. After converting documents by hand one too many times, I built a small browser converter for it. Before I get to that, here is an honest look at the options I've used, because the right one depends on what you're converting and how often.

Why bother converting to Markdown at all?

• Docs and READMEs. Most static site generators and Git hosts render Markdown natively.
• Notes. Markdown files stay portable across editors and are easy to diff and search.
• Static sites. Migrating old content into a Markdown-based site means getting it out of Word or HTML first.
• LLM context. Headings, lists and tables in plain text are compact and readable, and you avoid pasting a mess of layout noise.

Option 1: Copy-paste (and fix it by hand)

The default. Open the PDF or web page, select everything, paste it into your editor, and then rebuild the structure yourself.

Good for: a paragraph or two.

Downsides: headings become plain lines, lists lose their markers, tables collapse into runs of text, and links usually vanish. PDFs are especially bad, because line breaks follow the page layout rather than the sentences. For anything longer than a page, you spend more time repairing than reading.

Option 2: Pandoc

Pandoc is the reference tool for document conversion, and if you're comfortable on the command line it's hard to beat for Word documents:

pandoc input.docx -t gfm -o output.md --extract-media=./media

gfm gives you GitHub-flavored Markdown, and --extract-media pulls embedded images into a folder. You can also convert HTML you've saved:

pandoc page.html -f html -t gfm -o page.md

Good for: repeatable, scriptable conversions, batch jobs in CI, and anyone who wants full control over output options.

Downsides: you need to install and configure it. It doesn't read PDFs as input, so PDFs need a separate extraction step first. For a web page you have to download the HTML yourself, and you will often get navigation, footers and other page chrome mixed in with the article.

Option 3: Other command-line and library routes

For PDFs, people often chain a text extractor (like pdftotext from poppler-utils) with some manual formatting:

pdftotext -layout spec.pdf spec.txt

That gives you the text, but not Markdown structure. You still have to add headings and lists yourself. Scanned PDFs are another story: they're images, so you need OCR before any of this works.

Good for: quick text extraction when structure doesn't matter much.

Option 4: Online converters

Browser-based converters trade control for convenience: upload a file or paste a URL, get Markdown back. Nothing to install, which matters when you're on a borrowed machine or helping a non-technical teammate.

Things worth checking with any online converter:

• Which formats it actually accepts (many only handle one or two).
• Whether it keeps headings, lists, links and tables.
• What it does with your files afterwards. Read the privacy page, and don't upload sensitive documents to any web service you haven't vetted.
• What the free limits are.

The one I built: doctomd

This is the gap I wanted to fill for myself, so I built doctomd. It runs in the browser. You upload a Word (.doc/.docx), PDF, Excel, PowerPoint, EPUB, HTML, CSV or JSON file, or paste a public web page URL, and you can preview, copy or download the result as a .md file.

What it keeps: headings, emphasis, lists, links, simple tables and images, when the source file exposes them.

To be upfront about the limits:

• Complex layouts need manual editing. Multi-column PDFs, nested tables and heavily designed documents won't come out perfect.
• Scanned PDFs need OCR, which is only on the paid plans. The free tier works on text-based PDFs.
• The free tier is small: 3 conversions per day without an account, files up to 10MB, PDFs up to 3 pages. Paid passes raise that to 20 or 50 conversions per day, with bigger files and longer PDFs. They are one-time payments, not subscriptions.
• Files are processed temporarily and removed after conversion, but I'd still say: don't upload highly sensitive or regulated documents to it, or to any online converter.
• It is not scriptable the way Pandoc is. If you're converting hundreds of files in a pipeline, use Pandoc.

So which should you use?

My own split is roughly this: Pandoc for anything repeatable, a browser converter for the one-off "a client just sent me a PDF" moments, and copy-paste only for tiny snippets.

A few tips whatever tool you use

1. Check the heading levels. Converters often turn a document title into # and everything else into ##, or the other way round. Fix the hierarchy before publishing.
2. Look at tables first. They're the most likely thing to break. Simple tables convert well; merged cells rarely do.
3. For LLM context, trim before you paste. Remove repeated headers, footers and page numbers. It saves tokens and helps the model focus.

If you have a conversion workflow I haven't covered, I'd like to hear about it in the comments, especially for awkward PDFs.