How Pridocs Converts Files Without Uploading Them

What happens when you drop a file

When you drag a file onto a Pridocs tool (or click to choose one), your browser hands the page a File object using the standard, built-in File API — the same browser feature every website uses to let you attach a file to a form. At this point the file exists only as data in your browser tab's memory. Pridocs' code never calls a network function like fetch or XMLHttpRequest to send that file anywhere; there is simply no upload step in the code path.

What happens next depends on the tool, because different file types need different processing engines — all of which run inside your browser tab:

• Viewing or rasterizing a PDF (PDF to JPG/PNG, and reading pages for OCR) uses PDF.js, the open-source PDF renderer built by Mozilla for Firefox. It parses the PDF and draws each page onto an HTML <canvas> element, from which the image is exported.
• Editing a PDF's structure (merge, split, rotate, crop, watermark, page numbers, redact, sign) uses pdf-lib, a JavaScript library that reads and rewrites the PDF file format directly, byte by byte, without ever rasterizing it.
• Word document conversion (DOCX to HTML, Markdown, TXT, or PDF) uses Mammoth.js to parse the DOCX file's internal XML and turn it into clean HTML, which is then reformatted as needed.
• OCR (making a scanned PDF searchable) uses Tesseract.js, a JavaScript port of the Tesseract OCR engine compiled to WebAssembly (WASM) — real, compiled C++ image-recognition code running at near-native speed in your browser — inside a background Web Worker so the page doesn't freeze while it reads text off the page image.
• Audio and video tools (audio conversion, video to MP3/GIF, Song2Vid) use FFmpeg.wasm, which compiles the real FFmpeg encoder/decoder to WebAssembly. The first time you use one of these tools, your browser downloads the FFmpeg engine itself (a few megabytes of code, currently served from the public unpkg.com CDN) — this is the software, not your file. Once it's loaded, your actual audio/video data is processed by that engine locally and is never sent anywhere.
• Song Analyzer uses Essentia.js (music/audio analysis algorithms compiled to WebAssembly) for tempo (BPM), key, loudness and energy, plus TensorFlow.js with Essentia's MusiCNN models for genre, mood, danceability and acousticness estimates. On first use, your browser downloads those model files (a few megabytes each) and caches them locally — again, that is the analysis software, not your song.
• AI Background Remover runs an on-device image model (@imgly/background-removal) in your browser. The model weights download on first use and are then reused from cache; your photo stays on the device.
• Simple image tools (resize, format conversion, filters, EXIF strip, watermarks) use the browser's built-in Canvas 2D API directly — no external library is even needed to read pixels, resize, or re-encode an image.
• ZIP archives use JSZip in the browser. Invoice PDF and Markdown to PDF use pdf-lib. Speech-to-text uses the browser's Web Speech API (engine depends on your browser/OS).

Why your file never reaches a server

All of the processing described above — PDF.js, pdf-lib, Mammoth.js, Tesseract.js, FFmpeg.wasm, Essentia.js, TensorFlow.js models, and the Canvas API — runs using APIs your browser already provides locally. None of it requires sending your file's bytes to a remote server, so Pridocs' code simply never does. The only network requests a Pridocs tool can make are: loading the page itself, and one-time downloads of processing software (for example FFmpeg's engine binary, Tesseract's language data, Essentia/TensorFlow music models, or the background-removal model) — never your file.

You don't have to take our word for it. Open your browser's Developer Tools (F12), go to the Network tab, and convert a file. You will not see any outgoing request containing your file's data.

Source code

Pridocs' source code is public on GitHub, so you can verify everything on this page yourself instead of trusting a description of it: https://github.com/jeeten15-spec/pridocs

File size & performance

Because everything runs on your device rather than a server, performance depends on your device's own RAM and CPU rather than ours. We recommend keeping individual files under roughly 50–100 MB for a smooth experience — very large PDFs, videos, or image batches can run slowly or fail if your browser tab runs out of memory.

If you regularly work with larger media (for example long songs in Song2Vid), you can often stretch what the browser can handle by giving Windows more virtual memory — letting it use free space on a fast SSD as overflow when RAM is full. In Windows: Settings → System → About → Advanced system settings → Performance → Settings → Advanced → Virtual memory → Change, then set a larger custom paging file on an SSD drive. This does not upload your files anywhere; it only changes how your own computer manages memory. Results vary by device, and a hard limit still applies inside a single browser tab, but many people find this tip lets them finish jobs that previously crashed.

What about very large files or higher quality than a browser can deliver?

This does not exist today — every tool on Pridocs right now runs exactly as described above, entirely in your browser. We are considering an optional, clearly-labeled paid subscription tier in the future for cases the free browser-only tools genuinely cannot handle well, such as very large media files or conversions where in-browser processing can't match server-grade quality. If it ships, it will be an explicit, separate, opt-in choice — clearly marked wherever it's offered — and files sent to it would be deleted immediately after processing. It would never be silently mixed into the free tools described on this page.