Built the way engineers expect.
A technical overview of how DynaSparks Tools work, what runs where, and what to expect when you integrate or self-host.
Browser-first engines
Heavy work — PDF parsing, rendering, OCR inference — runs in WebAssembly inside dedicated Web Workers. The UI thread only handles interaction.
Privacy-first architecture
Documents never leave the device for local tools. Optional server features are separate services that must be enabled and are announced before any upload.
Strict security headers
Content-Security-Policy without unsafe-eval for the document, cross-origin isolation (COOP/COEP) for threaded WebAssembly, no embedded PDF JavaScript execution.
Verified output
Every export path is tested by reopening the produced file in an independent parser. Secure redaction is checked with byte-level leak scans.
Runtime model
- PDF engine
- PDFium compiled to WebAssembly, pinned per release, the single writer for every mutation and export.
- Rendering
- PDF.js for page rendering and text layers behind a viewer adapter.
- OCR
- PaddleOCR PP-OCRv5 models through ONNX Runtime Web (WebGPU when available, otherwise WASM); models are self-hosted and checksum-verified.
- Storage
- Origin-private file system for working copies, autosave and crash recovery.
- Offline
- Progressive web app; engines and models are cached after first use.
Integration
Tools are standard web applications: link to https://dynasparks.com/tools/edit-pdf from your own product, or deploy the Tools area on its own subdomain from the same build.
An optional server-side document AI service (structured DOCX/Markdown/JSON/XLSX export) ships as a self-hostable container with a health endpoint, upload limits and automatic file deletion.
A public HTTP API for the tools is not available yet. If it ships, it will be announced here with documentation; nothing on this site should be read as an API commitment.