Methodology
Every converter here runs the same three-stage pipeline, entirely on your device. Nothing about a file is sent to a server.
Parser, then HTML, then print engine
A converter first parses your file into a structured tree: Markdown and notebook cells go through the remark toolchain, CSV through a delimiter sniffer, and so on. That tree is turned into plain HTML, with code highlighted by Shiki using the same TextMate grammars VS Code ships and math typeset by KaTeX into vector output. The HTML is then written into a hidden document and handed to the browser's own print engine, which paginates it and produces the PDF. There is no PDF library serializing bytes; the same engine that prints any web page prints your document.
What runs where
Parsing and highlighting happen in a Web Worker, off the main thread, so the page stays responsive on large files. The main thread only assembles the preview and handles the few things that need a live DOM, such as rendering mermaid diagrams and sanitizing embedded HTML output with DOMPurify inside a sandboxed frame. On phones a single worker is used to keep memory in check.
Why an upload is not possible
The privacy claim is enforced by a Content Security Policy, not just a promise. The policy sets connect-src 'self', which blocks the page from opening a network connection to any other origin. With no outbound connection allowed, there is no code path that could upload your file even if one were written by mistake. You can verify this in your browser's developer tools: convert a file with the network tab open and watch that no request carries it, or disconnect from the network and confirm conversion still works.
Honest limits
Browser rendering has boundaries, and each tool states its own in an FAQ. Mermaid diagrams need JavaScript enabled, KaTeX covers a large subset of LaTeX rather than all of it, and scanned PDFs without a text layer cannot have text extracted. Where a format cannot be handled well, the tool says so rather than producing a broken file.