Smallpdf VS pdfmdtools

pdfmdtools's answer:

The conversion runs entirely inside your browser. The file you drop in is never uploaded — nothing is sent to a server, so nothing is stored, logged or queued. Because there is no download, no account and no waiting room, the result appears as soon as the conversion finishes. That architectural choice is the whole product: most converters in this category accept an upload, process it remotely and hand back a download, which is exactly the step people handling contracts, invoices, medical notes or unpublished drafts want to avoid.

pdfmdtools's answer:

Three concrete reasons. First, privacy by construction rather than by policy — the file cannot leave your machine because the code that reads it is running on your machine. Second, output aimed at Markdown that is actually usable: GitHub-Flavored Markdown with real heading levels, list items and code blocks, not a wall of plain text. Third, honesty about limits. Scanned PDFs have no text layer, and instead of returning an empty or silently broken file, the tool tells you it cannot convert them. Two-column layouts come out interleaved, and table cells flatten to one line per row — that is stated up front, and every one of those behaviors is reproducible against a public test corpus of 18 PDFs, each built to fail in one specific way, with the measured output published alongside it.

pdfmdtools's answer:

People who already work in plain text and need to move a document into it: developers and technical writers converting specifications into repositories or static-site content, researchers and students turning papers into notes, and anyone maintaining documentation who receives PDFs but works in Markdown. A second group is the privacy-sensitive one — legal, medical, HR and finance staff who are permitted to read a document but not to upload it to a third-party service. The tool is deliberately self-service: no sign-up, no team management, nothing to configure.

pdfmdtools's answer:

It started as a practical problem: converting PDFs to Markdown kept meaning handing confidential documents to a website and hoping the output was clean. Neither half of that was acceptable. Browser technology had reached the point where a full PDF parser could run client-side without a server round trip, so the tool was built around that single constraint — if the file never leaves the browser, the privacy question stops being a matter of trust. The other half of the story is the testing: after noticing that converters disagree wildly on the same input, a public corpus of small purpose-built PDFs was assembled, each isolating one behavior — column order, missing heading structure, absent text layers — so that claims about conversion quality could be measured instead of asserted.

pdfmdtools's answer:

The PDF parsing and text extraction is handled by PDF.js, Mozilla's JavaScript PDF renderer, version 3.11.174, used under the Apache License 2.0 — it is the only third-party library in the build, and its licence notice is preserved in the bundled files. Everything above that — the Markdown serialiser that turns positioned text items into headings, lists and code blocks, the user interface and the conversion logic — is plain HTML, CSS and JavaScript with no framework and no build-time dependency beyond the bundling of PDF.js itself. The pages are static files served from a CDN, so there is no application server, no database and no backend that could receive a document. The source-code licence is listed as Proprietary: the site's own source is not published, while the test corpus of PDFs is released separately under CC0.

pdfmdtools's answer:

No named corporate customers are publicly disclosed. pdfmdtools is a self-service browser tool with no accounts and no way to identify who uses it — by design, since nothing about a conversion is transmitted anywhere. It is used primarily by individuals and small teams rather than by large organisations with a procurement relationship.