“Your file stays private” is meaningful only when the systems, data flows, and assumptions are clear. A browser-based converter can remove the need to upload a document to a processing server, but it cannot make an infected device safe or override an organization's retention rules.
A small threat model helps distinguish architectural privacy from marketing language. It also makes tool selection proportional: a public brochure and an unreleased acquisition agreement do not require the same controls.
Identify the asset and its sensitivity
Start with what the PDF contains. Examples include public documentation, internal procedures, personal records, customer data, contracts, source code, research under embargo, or regulated health and financial information. Note whether the converted Markdown will be equally sensitive. Plain text can be easier to search and copy, so conversion may increase practical exposure.
Identify required properties: confidentiality, integrity, availability, and provenance. A public report may not need confidentiality but still requires integrity. A legal archive needs a clear relationship between the original and derivative. A temporary note may not need long retention.
Do not label a document “non-sensitive” merely because it lacks passwords. Names, addresses, business plans, unpublished prices, and combinations of ordinary facts can still be confidential.
Map browser-side data flow
In a client-side workflow, the user selects a local file and JavaScript reads its bytes. A library such as PDF.js parses those bytes in the browser process. The resulting Markdown can stay in memory until the user copies or downloads it.
Verify this architecture with developer tools. Clear the network log, begin recording, select a test PDF containing no real confidential data, and convert it. Look for uploads, unusually large requests, object-storage URLs, or API calls triggered by selection. Repeat after disabling the network: if conversion still works after the application is loaded, remote processing is unlikely to be required.
These checks have limits. Minified code may be hard to inspect, service workers can cache resources, and browser extensions can observe pages according to their permissions. Use a managed browser profile or a clean environment for higher-sensitivity work.
Account for the local device
Local processing shifts trust toward the device. Malware, remote-management tools, screen capture, clipboard managers, backup software, and extensions may access the source or output. Downloaded Markdown may sync automatically to cloud storage.
Review where downloads go, whether full-disk encryption is active, who can sign into the device, and whether temporary files are created. Browser memory is usually cleared when the process ends, but crash reports and swap behavior are controlled by the operating system.
For shared computers, do not assume that closing a tab removes downloaded files or clipboard history. Use an approved device and storage location.
Compare server and cloud conversion
A server converter adds network transport, edge proxies, application servers, queues, temporary storage, logs, backups, and operational access. TLS protects transport but does not mean the provider cannot access the file after receipt.
Review whether files are stored, how long they remain, where processing occurs, whether subprocessors are used, and how deletion is verified. A claim such as “deleted after one hour” is different from “never uploaded.” Both can be acceptable under different policies, but they are not interchangeable.
Cloud OCR and layout services may retain diagnostic samples or use data under account settings. Check the actual agreement and configuration rather than relying on a generic product page.
Include downstream AI services
A common workflow converts locally and then pastes Markdown into an AI assistant. At that moment, the text leaves the device even though the PDF did not. The same applies to remote embeddings, translation, summarization, and grammar tools.
Map each downstream provider, account type, retention setting, and access policy. Redact only with a defined process; replacing names inconsistently can make analysis misleading. If data cannot leave the device, use local downstream tools or stop after local conversion.
Browser conversion is one segment of the chain, not a privacy label for everything that follows.
Consider integrity and malicious PDFs
PDF is a complex format. A robust parser should be kept current because malformed documents can target vulnerabilities. Open untrusted files in a patched browser and avoid enabling embedded scripts or launching attachments. Conversion output can also contain links to malicious destinations.
Do not execute commands copied from an unknown PDF without review. Markdown renderers may allow HTML or remote images; configure the destination appropriately. If a converted document will be published, inspect links, embedded HTML, and image references.
Preserve a checksum of important source files so accidental or malicious changes can be detected. The Markdown should be treated as a derivative, not as proof of the original document's authenticity.
Define retention and deletion
List every copy: original PDF, browser download, Markdown file, ZIP archive, clipboard, synced folder, version-control repository, email attachment, and backup. A deletion claim is incomplete if it covers only the primary file.
Choose retention based on purpose. Temporary conversion may require immediate cleanup; audited publishing may require the source to remain available. If the Markdown enters Git, remember that deleting the current file does not remove earlier commits.
Avoid storing confidential documents in public repositories or analytics events. Logs should capture file size, outcome, and error category only when those fields are necessary, not document content or identifying file names.
Match controls to risk
For public PDFs, a normal updated browser may be sufficient. For ordinary internal documents, use a managed device, local conversion, approved storage, and no unreviewed extensions. For regulated or highly confidential files, follow the organization's security and legal requirements; a free web tool may not be an approved environment even when processing is local.
Document the decision and unresolved assumptions. Test with non-sensitive samples before using a new workflow. The browser parsing guide explains the technical path, while the batch QA guide shows how to retain evidence across many files.
