mrmps/pdf2md: a Next.js wrapper around @opendocsg/pdf2md that converts PDFs in the browser

The problem is not conversion, it is where the conversion happens

Most PDF to Markdown converters are services. You send the file to an endpoint, the endpoint runs a parser, you get Markdown back. That is fine for public documents and awkward for anything else. Contracts, medical records, internal specifications and unpublished drafts are exactly the documents people most often want in Markdown, and they are exactly the documents that should not leave a laptop. mrmps/pdf2md takes the other route: the README states that all processing happens locally in the browser and that no files are uploaded or stored. The target reader is a developer or writer who has a PDF open in a tab and wants Markdown out of it without thinking about a data processing agreement. The project is built with @opendocsg/pdf2md, a library that already does the parsing; what this repository adds is a Next.js interface, a drag and drop target, a preview pane and a download button.

What the browser actually does with your file

The README describes a four step flow. You drop a PDF onto the page or pick one with a file selector. The application hands the file to @opendocsg/pdf2md, which extracts text and structure. The result is rendered as Markdown in the page. You then download it or copy it to the clipboard. The README does not describe a worker thread, a WebAssembly build, or any chunking strategy, so based on the repository layout and the documentation alone there is no evidence that parsing is off the main thread. That matters: PDF parsing in JavaScript is CPU bound, and a large file will occupy the tab while it runs. The privacy claim holds regardless, since the file never crosses the network boundary. The performance implication is the part the README leaves open, and the only guidance it gives is a soft ceiling of 10MB for best performance.

Getting it running locally

The README gives a standard Node workflow. Clone the repository, change into the directory, install dependencies with pnpm, npm or yarn, then start the development server and open http://localhost:3000. The exact commands are git clone https://github.com/mrmps/pdf2md followed by cd pdf2md, then pnpm install, then pnpm dev. No environment variables, API keys or configuration files are mentioned anywhere in the README, which is consistent with a tool that has no server side component. There is no documented production build or deploy step either; if you want to host it yourself you are on your own, and the homepage listed for the project is a hosted instance at pdftomarkdown.co. There are no published releases in the material supplied, so there is no versioned artifact to pin. You are tracking the main branch.

The 10MB ceiling and the formatting that does not survive

Two limits are stated plainly. The FAQ recommends keeping files under 10MB and warns that larger files may slow down the browser. The second is more consequential for anyone converting technical documents: the README says headings, paragraphs, lists, tables, bold and italic text and links are preserved when possible, and that complex layouts, images and advanced formatting may not be fully preserved. Images are the sharp edge. A PDF full of diagrams will produce Markdown that references nothing, because there is no documented image extraction step. Multi-column academic papers are the other likely failure case, since column detection is a layout problem rather than a text problem. And if your PDF is a scan with no text layer, there is no OCR mentioned in the material at all, so the output will be empty or near empty. This is the wrong tool for any of those three cases.

How it differs from a full document pipeline

The obvious alternative is a Python pipeline built on Marker or PyMuPDF, or a service like the hosted converters. The difference is not accuracy first, it is architecture. A Python pipeline runs on a machine you control, can batch thousands of files, can call an OCR engine on scanned pages, can write images to disk and rewrite the Markdown to point at them, and can be scheduled. mrmps/pdf2md does one file at a time, interactively, in a tab, with no OCR and no image handling. The trade is setup cost against capability. If you need to process a directory of 400 PDFs overnight, a browser tool is the wrong shape regardless of how good the parser is. If you need to convert one contract while sitting in a meeting, spinning up a Python environment is the wrong shape. The project also inherits its parser from @opendocsg/pdf2md, so its output quality is bounded by that library rather than by anything in this repository.

Maintenance cost is low, but so is the surface you control

The README lists the licence as MIT and points at a LICENSE file in the repository. MIT is permissive: it allows commercial use, modification and redistribution provided the copyright notice and licence text are retained. That is the general shape of the licence, not legal advice, and the material supplied does not include the LICENSE file contents, so confirm the file matches the README claim before you depend on it. On maintenance: the project has no published releases, so there is no changelog to read and no version to pin. Upgrading means pulling main and reinstalling. The dependency that actually determines output quality, @opendocsg/pdf2md, is maintained separately, which means a fix to extraction behaviour arrives here only when this repository bumps the dependency. There is no documented test suite or CI configuration in the material, so you cannot tell from the README whether a change to the parser would be caught before it reaches users.

Who should use it, and what to check first

Use it if you convert single, text-heavy PDFs of modest size and the file cannot leave your machine. The offline claim is worth noting here: the README states that once loaded, the app works without an internet connection, which follows from there being no server side processing. That makes it usable on an air-gapped laptop, assuming the page is already cached. Do not use it for scanned documents, image-heavy reports, or batch jobs. Before adopting it inside a team, run pnpm dev locally and feed it the three PDFs that break every converter you have tried. If those come out clean, the tool does what it says. If they do not, the problem is in @opendocsg/pdf2md and no amount of work on this repository's interface will fix it.

Editorial conclusion

Adopt mrmps/pdf2md if your PDFs are under roughly 10MB, you want the conversion to happen on the user's machine, and you are willing to accept the extraction quality of @opendocsg/pdf2md as-is. Do not adopt it if you need images, multi-column layout fidelity, OCR for scanned pages, or a batch pipeline, because none of those appear in the documentation. Before committing, clone the repo, run pnpm dev, and test it against three or four of your own worst-case PDFs rather than the sample the README implies.

Official sources

1. Issues
2. mrmps/pdf2md on GitHub
3. Project website
4. README