Most “Word to Markdown” workflows jump straight to Pandoc flags or paste-and-pray into an editor.
This guide starts one step earlier: when browser-local conversion beats a cloud upload, what structure actually survives, and how to review output before it hits GitHub or Obsidian.
When local conversion is the better default
Upload converters are fine for throwaway files. They’re a poor fit when:
- The draft is client work or unpublished writing
- You don’t want another account just to convert one file
- You need editable Markdown in under a minute
If the file can be processed in your browser, you keep the document on your device.
Prepare the DOCX
- Use a modern
.docx(old.doc→ open in Word → Save As DOCX). - Prefer real heading styles (Heading 1–6), not just bold big text.
- Keep tables simple when possible.
What usually survives well
- Headings (H1–H6)
- Bulleted / numbered lists
- Tables
- Links
- Bold and italic
Honest limits
- Complex page layouts may need a quick cleanup
- Embedded images often need a manual pass
- Footnotes and exotic Word features vary
A simple workflow
- Open a browser-local converter such as WordToMarkdown
- Drop your
.docx - Review the Markdown beside the converter
-
Copy into Obsidian / Notion / a docs PR — or Download
.mdfor GitHub
Checklist before you publish the Markdown
- [ ] Heading levels make sense in the new context
- [ ] Tables render
- [ ] Links still point where you expect
- [ ] Images added back if needed
- [ ] No leftover Word junk (extra spaces, broken list markers)
That’s it: portable text, without turning a Word file into another upload.
Try one file here: wordtomarkdown.net
Top comments (0)