Engineering notes
SnapConv is a local file toolkit that happens to be a website. These are the engineering decisions that keep it private, honest, and fast.
Static by construction
The product is a statically exported site. There are no route handlers, server actions, or processing APIs, so there is no server that could receive a file even by accident.
One registry, one source of truth
Formats, operations, tool pages, conversion routes, recommendations, and sitemap entries are generated from a typed registry of serializable metadata.
Measure before promising
Each tool probes the browser for real decode and encode support — including canvas encoding and lazy WebAssembly codecs — and only advertises the formats that passed. Unavailable codecs are explained instead of silently substituted.
Verify every result
Generated files are checked for MIME type, magic-byte signature, and a decode or reopen probe before they are offered for download.
Bound the work
A shared scheduler owns concurrency, downgrades resolution when a page or image exceeds the memory budget, cancels deterministically, and disposes canvases, workers, and transferable buffers.
Test for the browser you have
Contracts and processors run in unit and real-browser suites, and end-to-end flows run in Chromium, Firefox, and WebKit — including no-egress tests that fail if a selected file ever triggers a network request.
Building blocks
- Next.js static export with React and strict TypeScript
- Zustand for the in-memory processing queue
- Native image decoding, canvas encoding, Web Crypto, and streaming Blob pipelines
- PDF.js for parsing and rendering, pdf-lib for page manipulation
- client-zip for local ZIP packaging without a server round trip
Honest limits
Browser support is not uniform. AVIF encoding, animated formats, and heavy media codecs differ per engine, so those capabilities stay experimental until they pass their own fixture, memory, and cross-browser tests. Reporting a limitation is preferred over pretending the format is universal.