The normal document path
For a supported local workflow, selecting a document does not begin with an upload to a NoblePDF application server. Browser JavaScript reads the file through the file-selection APIs, processing code works on the bytes in memory or a worker, and the finished result is exposed as a browser Blob for download. The full editor can additionally use IndexedDB for local project recovery. That design is why NoblePDF describes itself as local-first rather than cloud-first.
What runs locally
NoblePDF self-hosts the runtime used by the current release, including PDF.js for PDF parsing/rendering, pdf-lib for many PDF construction operations, qpdf compiled to WebAssembly for supported structural PDF processing, Tesseract for OCR, and libraries used to read office-style formats. Self-hosting means the exact runtime bytes can be hashed and tested as part of a release and the editor does not depend on a public CDN being reachable.
Local execution does not mean every task is free of limitations. WebAssembly still runs inside the browser process and uses your device’s memory and CPU. OCR of hundreds of high-resolution pages can be expensive. Browser tabs can be suspended. Mobile devices have tighter memory limits than desktops. NoblePDF therefore reports errors rather than silently moving the job to an undisclosed cloud converter.
Persistent editor storage
The full editor has a different privacy profile from a one-shot converter because it can preserve local project state. Current editor code uses an IndexedDB database named PdfEditorLocal. IndexedDB is origin-scoped browser storage. That is one reason the long-term deployment separates the full editor onto app.noblepdf.com: a separate origin gives the browser a real storage boundary between persistent document projects and advertising code on the public site.
What NoblePDF deliberately keeps out of advertising
Document bytes, filenames, OCR results, signature strokes, annotations, form values and document passwords must not be turned into ad targeting or analytics fields. The pre-approval release contains no AdSense or Google Analytics runtime at all. When advertising is introduced later, the first approved inventory is intended to be editorial content such as guides, not Save, Download, Convert, result, loading or editor surfaces.
Network exceptions you control
The clearest current exception is HTML-to-PDF. An HTML file can reference remote CSS, images or fonts. NoblePDF sanitises external resources by default, and the tool provides an explicit option to allow them. If you enable that option, the browser can contact the hosts referenced by the HTML. This may be useful for a page that depends on remote assets, but it is not appropriate when you need strict network isolation.
How to verify the boundary yourself
Advanced users can open browser developer tools and watch the Network panel while loading a document. In the full editor, runtime requests should be for same-origin assets such as workers, WebAssembly and language data rather than an upload endpoint carrying the PDF. You can also inspect site storage to see the local IndexedDB entry. These checks are useful because privacy claims are stronger when they can be observed rather than merely trusted.
Why this architecture matters
A privacy promise based only on policy can be weakened by a later configuration mistake. NoblePDF therefore keeps the persistent editor on a dedicated application origin with a Content Security Policy that excludes advertising hosts. The goal is defence in depth: document processing behaviour, browser origin isolation, CSP, release tests and conservative monetisation rules all point in the same direction.