Repository navigation
Support for .doc extensions #23
Description
Activity
created PR #36
Reacted by Gagan BansalPatiently waiting for good news.
Just wanted to comment, I ran a check of file counts across our server, where I was considering using markitdown:
- PDF - 1,150k files
- JPG - 243k files
- DOC - 112k files
- XLS - 70k files
- XLSX - 69k files
- DOCX - 46k files
I think this demonstrates just how important DOC file handling is, even in 2025.
On a side note, what's not shown in the above list is the number of PDFs that are generated content versus scanned documents. Most are probably scanned, and 95% of the scanned PDFs should be searchable images.
Other related PRs / discussions not already linked above:
Reacted by alexshmmy and Andrewraised PR #1316
Hi, I'm interested in working on this issue if it's still open. I'm new to open source and would appreciate any guidance.
Reacted by Filipe LacerdaI saw that some people have already made an effort and developed this functionality, which shows its importance to the community. I'd like to better understand what the assumptions are after the PR and why there's been a delay in providing support for .doc files.
I've recently tested this, #1316 , works well on both linux and windows with no need for third-party installations (provided MS Office is installed on the Windows client).
The open-source LibreOffice has a CLI converter that also works for legacy .doc files. A bit bulky but doesn't require MS Office license and can be setup on linux machines.
- added a commit that references this issue
on Mar 13, 2026 - added a commit that references this issue
on Mar 19, 2026 Hi,
With the help of Claude and the open format specification of binary Word doc 98, I created my own package to parse the *.doc format.
It is written in Rust with a python binding.It works surprisingly well! With features like text box extraction and the preservation of titles translated into markdown.
You can try it using :
cargo install unword.
unword --input test.doc > test.mdyuchengpersonal did a greate pull request using antiword and textract . But from experience, the package I made works much better than antiword.
Note: I'm a developer, I understood the generated code. But the doc format specification is so complex that Claude was a huge help
- added a commit that references this issue
on Apr 11, 2026 - added 5 commits that reference this issue
on Apr 13, 2026 - added a commit that references this issue
on Apr 19, 2026 Hi is this issue still open for contribution? I'm new to open source and would like to help contribute!
Reacted by sacha schutzHi is this issue still open for contribution? I'm new to open source and would like to help contribute!
You may try making a PR with unword as parser backend. I have no time right now
Reacted by yousrae2004Hello! Is there any update on this?
i am a gssoc candidate and i would like to solve this issue pls can you assign it to me
Alright, I made a PR but I saw there were already others! I think it's going to be a long wait before a PR gets approved. So in the meantime, I published unword 0.2.2 with the Rust libraries compiled for Linux, Mac and Windows. The most advantage of my package is speed and optional text_box extraction .
So you just have to do this, it should work. If not , please create an issue .pip install unwordimport unword doc = unword.parse_doc(open("document.doc", "rb").read()) print(doc.body_text)- added a commit that references this issue
on Jul 29, 2026
Are you planning to offer .doc support in addition to the current .docx support?