Private Markdown to PDF: Converting Without Uploading Your Files

If your Markdown contains a contract draft, an unpublished paper, internal infrastructure notes, or your home address on a resume, it is worth knowing where the text goes when you convert it. Many web converters upload your document to a server, process it there, and send back a file. Some do not. The interface looks identical either way.

This guide covers the technical difference, how to verify which kind you are using, and the metadata question that most privacy discussions of PDFs miss entirely.

Client-side versus server-side

Two architectures, indistinguishable from the outside.

Server-side. Your text is transmitted over the network to the provider’s infrastructure. A process there parses the Markdown, renders it, generates a PDF, and returns it. Your document exists on someone else’s machine — in request logs, in memory, possibly in temporary files, possibly in a queue, possibly in a backup. How long it stays and who can read it depends entirely on the provider’s practices, which you cannot inspect.

Client-side. The page downloads JavaScript once. That code runs in your browser, parses the Markdown, renders it and generates the PDF locally. Your text is never sent anywhere because there is no request that carries it. The provider could not read your document if they wanted to.

The distinction is not about trust or good intentions. It is architectural: in one case the data is transmitted, in the other it is not. A well-intentioned server-side provider with a breach still leaks your document. A client-side tool has nothing to leak.

What “no upload” should mean

The phrase is used loosely. Some tools that say “your files are never stored” are still uploading them — they process and delete rather than not receiving. That is a meaningfully weaker guarantee: it depends on the deletion actually happening, on logs not retaining a copy, and on nothing intercepting in transit.

“No upload” should mean no network request contains your content. That is verifiable, which is the point.

How to verify a tool’s claims

Do not take any tool’s word for it, including this site’s. Three checks, in increasing order of how convincing they are.

1. The network tab

Open developer tools (F12, or Cmd+Option+I), select Network, then convert a document.

What you are looking for: any request whose payload contains your text. Sort by size — an upload of your document will be conspicuously larger than a typical asset request. Click a POST or PUT request and inspect the payload.

A client-side tool shows no such request. You will see the initial page load, fonts, scripts, and possibly analytics pings, but nothing carrying your content.

A caveat: analytics requests are normal and usually contain a page path, not your document. If you see a request with your Markdown in the body, that is an upload regardless of what the marketing copy says.

2. Convert with the network disconnected

More convincing, and takes ten seconds.

1. Load the tool’s page normally.
2. Disconnect from the network — turn off Wi-Fi, or use the Offline throttling option in the Network tab.
3. Paste your Markdown and convert.

If it produces a PDF, the conversion happened locally. There is no other explanation. If it fails or hangs, it needed a server.

This is the test worth doing once on whatever tool you settle on.

3. Content Security Policy and source inspection

For a stronger guarantee, look at what the page is permitted to do. In the Network tab, click the document request and read the Content-Security-Policy response header. A restrictive connect-src limits where the page can send data at all — connect-src 'self' means it cannot POST to a third party.

You can also read the JavaScript. Minified bundles are unpleasant but searchable: look for fetch(, XMLHttpRequest, navigator.sendBeacon, and WebSocket. This is more effort than most situations warrant, and it is available if the document genuinely matters.

What the privacy policy does not tell you

A few things worth checking beyond the conversion architecture, because “we don’t upload your document” can be true while other things are happening.

Analytics and session recording. Some session-replay tools capture DOM content and keystrokes. A tool that converts locally but runs full session recording is capturing your document text through a different channel. Check the network tab for requests to session-replay providers, and look for unusually chatty background requests as you type.

Third-party scripts. Any script on the page runs with full access to the page’s DOM, including your document text in the editor. A client-side converter loading five third-party scripts has five parties who could read your content. This is why connect-src in the CSP is worth checking.

Local storage. Client-side tools commonly autosave drafts to localStorage or IndexedDB so you do not lose work. That is local — a good thing for privacy relative to a cloud draft — but it does mean your document persists in the browser profile. On a shared machine that matters. Clearing site data removes it.

Crash and error reporting. Error reporters sometimes include page state in reports. Uncommon, worth knowing about.

Metadata your PDF leaks

This is the part most privacy discussions omit, and it is the one that has actually caused people problems.

A PDF contains more than the visible page. Generated PDFs commonly embed:

• Creation and modification timestamps, often to the second
• Producer and creator strings naming the software and version
• Document title, which may come from an HTML <title> rather than anything you chose
• Author, which some tools populate from the OS account name
• Local file paths in some pipelines, revealing your username and directory structure

The username-in-path case is the one to watch. A PDF whose metadata contains /Users/jordan.rivera/Documents/clients/acme-confidential/ reveals your name, your other clients, and your folder structure to anyone who opens the file properties.

Inspecting metadata

# Overview
pdfinfo document.pdf

# Everything, including XMP
exiftool document.pdf

# Look for embedded paths in the raw structure
strings document.pdf | grep -iE '/(Users|home)/' | head

pdfinfo is part of poppler-utils; exiftool is separately installed and more thorough.

Stripping it

# exiftool: remove all metadata
exiftool -all= document.pdf

# qpdf: rewrite structure, dropping metadata
qpdf --linearize --empty --pages document.pdf -- clean.pdf

# Ghostscript: full rewrite, most thorough
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.7 \
   -dPDFSETTINGS=/prepress \
   -dNOPAUSE -dQUIET -dBATCH \
   -sOutputFile=clean.pdf document.pdf

The Ghostscript route rebuilds the file entirely and is the most reliable, at the cost of re-encoding images. Check the output size and quality afterwards.

Setting metadata deliberately

Often better than stripping. A document with a sensible title and no author is less suspicious than one with all metadata removed, and more useful:

exiftool -Title="Quarterly Report" -Author="" -Creator="" -Producer="" document.pdf

In an HTML-based pipeline, the <title> becomes the PDF title, so set it intentionally rather than letting it default to a filename.

Genuinely private options compared

Method	Content stays local	Works offline	Install	Metadata risk
Pandoc	Yes	Yes	Yes, large	Low — may embed paths
WeasyPrint	Yes	Yes	Yes, small	Low
Desktop editor export	Yes	Yes	Yes	Moderate — often sets author
Client-side browser tool	Yes	After first load	No	Low — no OS account access
iOS Shortcuts	Yes	Yes	No	Low
Server-side web tool	No	No	No	Varies

A point in favour of browser-based tools that is rarely made: a browser has no access to your OS username or filesystem paths. It cannot embed them in the PDF because it cannot see them. Desktop applications routinely populate the author field from your account name.

Installed local tools — Pandoc, WeasyPrint, Obsidian, Typora — are genuinely private, and that deserves saying plainly. The privacy problem is specific to web tools that upload, not to web tools generally.

Threat models

“Private” depends on what you are protecting against. Being specific helps.

A curious or careless provider. Concern: your document sits in logs or storage, readable by staff or exposed by a breach. Client-side conversion or any local tool solves this completely.

Network interception. Concern: someone on the path reads your document. HTTPS addresses this for transmission; client-side conversion means there is nothing to intercept. On a hostile network, client-side is meaningfully better.

A shared or managed machine. Concern: drafts persist in browser storage, or the PDF stays in Downloads. Neither client-side nor local tools help here. Use a private window, clear site data, and check where the file was saved. If the machine is managed by someone else, assume the whole session is visible.

Regulatory obligation. Concern: HIPAA, GDPR, attorney–client privilege, classified material. Verify rather than assume. “It says it’s client-side” is not an assessment. If your obligations require documented controls, use an installed tool inside your own infrastructure, where the boundary is auditable. Many organisations prohibit pasting regulated content into any web page, and that policy is reasonable.

Recipient-side leakage. Concern: the person you send the PDF to learns more than intended. This is the metadata problem above, and it is the one that catches people who did everything else right. Check metadata before sending anything sensitive externally.

That last category is worth emphasising. Conversion privacy protects the document on its way to becoming a PDF. Metadata privacy protects it after you send it. They are different problems and the second gets far less attention.

A private workflow

For a genuinely sensitive document:

1. Verify your tool with the offline test, once.
2. Draft locally. Avoid pasting sensitive content into anything cloud-synced that you have not assessed.
3. Convert locally — installed tool, or verified client-side.
4. Inspect the metadata before it leaves your machine: exiftool document.pdf.
5. Strip or set it deliberately.
6. Check the visible content too. Comments, tracked-change remnants, and content hidden by CSS may still be in the PDF’s text layer. pdftotext document.pdf - | less shows what is actually extractable.
7. Send over a channel appropriate to the sensitivity. A carefully-private PDF emailed unencrypted has not achieved much.

Step 6 is worth doing. Content hidden with display: none is usually absent from the PDF, but content merely positioned offscreen or coloured to match the background can be fully present in the text layer and invisible on the page. pdftotext reveals it.

Try it yourself

The editor here is fully client-side: markdown-it parses your text, Paged.js paginates it, and the browser’s own print engine produces the PDF — all locally. Nothing you type is transmitted, drafts autosave to your browser’s local storage rather than a server, and because it runs in a browser it has no access to your OS username or file paths to embed as metadata.

Please do not take that on trust. Run the offline test: load the page, disconnect, convert anyway. It works, and that is the only assurance worth having.

The FAQ covers the specifics. For installed alternatives, the Pandoc comparison and platform guide both cover local tooling — and the resume guide is worth reading if the document you are converting is one with your home address on it.