“100% local” is easy to write on a landing page. But what concretely happens when you drop a 200-page PDF into Document Flare? A guided tour of the architecture, from click to byte.
The file never leaves: everything starts with a local read
When you drop a document, the browser reads it through the File API: the bytes are loaded into the page’s memory, just as installed software would. From there, all the work happens in the browser process — there is simply no server-side endpoint capable of receiving a document.
This is an architectural choice, not a setting: the application is a static site. It serves files (HTML, JavaScript, fonts) at load time, then no longer needs the network. You can cut the Wi-Fi after loading: the tools keep working.
Samsung T7 Shield — 1 TB portable SSDFast, shock-resistant SSD; sized for a complete digitized archive.affiliate
Four specialized engines, one machine: yours
Behind the buttons, Document Flare relies on the same libraries as desktop software:
- pdf-lib for structural manipulation: merge, split, rotate, reorder, add pages, write metadata. This is the library that rewrites the PDF object tree — the same family of tools desktop applications use.
- PDF.js (Firefox’s rendering engine) to display pages: organizer thumbnails, rendering for image conversion, text extraction. When you see a page thumbnail, the same engine that draws Firefox Reader is drawing it.
- Tesseract.js for OCR: the character-recognition engine compiled to WebAssembly runs in the browser and adds the text layer to scans, with no recognition server.
- Transformers.js for AI: semantic search vectorizes passages of your document with a multilingual model executed locally — downloaded once, then served from cache.
Workers: keeping a smooth interface on large files
Parsing 200 pages, rasterizing images or computing embeddings are heavy tasks. Run on the main thread, they would freeze the interface. Document Flare offloads them to Web Workers: parallel execution threads that process the document in the background while the interface stays responsive — progress displayed, cancellation possible, no feeling of a crash.
This is also what enables batch processing: page-by-page OCR advances without blocking, each processed page feeding the progress bar.
Memory: the honest, real limit of local processing
The local approach has one real constraint: your device’s memory. A PDF of several hundred MB, or high-resolution renderings of dozens of pages, draws on the browser’s RAM. That is why the displayed limits exist (50 MB per file on most tools, 1,000 pages): they are not commercial restrictions but technical guardrails so that processing stays reliable on an ordinary machine.
When a document exceeds these limits, the honest strategy is to split it and process it in segments — possible in the same local environment.
Why this architecture changes things
This design is not just a technical feat; it has direct consequences:
- Structural privacy: there is no processing server to compromise or to take on faith. The exposure surface shrinks to your device.
- Zero queue: no server quota, no “upgrade to premium to process this file”. The available power is your machine’s — immediately.
- Verifiable transparency: the Network tab of the developer tools shows the absence of uploads; the code is readable. The promise can be checked instead of merely believed.
The browser has become a serious computing platform: WebAssembly for native engines, workers for parallelism, the File API for document access. Document Flare simply exploits what the platform already offers — so your paperwork stays where it belongs: with you.
The right hardware
Samsung T7 Shield — 1 TB portable SSDFast, shock-resistant SSD; sized for a complete digitized archive.affiliate
