Rebuild readable objects and page trees, reopen with recovery disabled, compare page and resource inventories, then render every recovered page independently.
~/jessejaffe/work/openable
all work
digital preservation + file recovery / 2026
Openable
I built a local-first health check and recovery tool that finds damaged files, verifies what survived, and creates separate copies without uploading originals.
the problem
A file can still exist while its structure is broken.
Interrupted saves, downloads, transfers, and storage errors can damage headers, indexes, checksums, endings, or content while leaving a file in place.
Openable makes the uncertainty legible: inspect the bytes locally, preserve what can be recovered, and verify a derived copy before offering it for download.
visual walkthrough
From a private scan to a verified recovery copy.
Openable keeps each decision visible: what was read, what survived, and what can safely be returned.
-
01
Choose what Openable can read
Select a folder in Chrome or Edge, or choose a few files. The browser grants read access only to the files the person explicitly selects.
- nothing is uploaded
- originals stay untouched
- no account or server-side file metadata
Local inspection is the product boundary -
02
Inspect the structure that survived
Streaming bytes into the C++20 core gives each result a detected format, extension-versus-content warnings, conservative damage checks, and a SHA-256 fingerprint.
Scope: the foundation release recognizes 857 formats from the PRONOM/DROID V124 signature registry, then applies deeper checks to supported PDF, JPEG, PNG, and ZIP files.
Corruption becomes an inspectable set of surviving signals -
03
Recover the smallest useful unit
The recovery path is format-specific and conservative: complete JPEG endings or recoverable coefficients, PNG rows, readable PDF pages and objects, or surviving ZIP entries.
- every recovery is a separate derived copy
- partial results stay labeled partial
- unsupported or unsafe cases refuse a download
Recovery follows surviving pages, rows, blocks, or entries -
04
Open, decode, inspect, verify
A successful-looking download is not enough. Openable reopens the output, rescans it, and uses independent validators before making the recovery available.
Evidence: PDF.js renders recovered pages, raster checks compare decoded pixels, ZIP checks verify entry bytes and CRCs, and every scan can export a structured JSON manifest.
A recovery result carries receipts, not just a button
technical brief
README.md
A browser host around a portable C++ preservation core, with independent verification and a separate open benchmark harness.
01 / architecture
One preservation engine, two hosts
The React and TypeScript browser host owns permissions, recursive traversal, progress, cancellation, recovery controls, and manifest export. It streams bounded chunks into the same C++20 engine that can run natively or compile to WebAssembly.
01
browser host
File System Access API + scan orchestration
→
02
streamed bytes
bounded chunks + cancellation between files
→
03
C++20 core
format detection, fixity, diagnostics, recovery
The core does not depend on browser APIs. A native directory adapter and the WebAssembly bridge feed the same FileScanSession model, so preservation rules remain in one portable layer.
02 / recovery units
Format-specific recovery without pretending missing data exists
Openable reports the unit it can actually recover, rather than turning a partially useful file into an unexplained pass or a blanket failure.
Check endings and decoder output, append a missing end marker when safe, or salvage recoverable coefficient blocks without another lossy quantization pass.
Validate chunks, CRCs, and zlib streams; preserve complete decoded rows for supported static non-interlaced 8-bit images.
Find surviving local headers, verify stored or deflated payloads, rebuild standard or damaged ZIP64 archives, and include a recovery report inside the output.
03 / verification
A returned file must earn the download
Recovery messages never decide whether content survived. Each format has an independent check that can confirm exact content, identify a partial result, or keep the download withheld.
scan bytes
format-specific diagnosis
derived recovery copy
↓
reopen + rescan + SHA-256
↓
PDF.js pages | raster RGBA | ZIP bytes + CRC
↓
verified / partial / safe refusalThe browser keeps a recent-scan library locally, stores no server-side file metadata, and exports structured per-file results. Passwords are never guessed or bypassed, and physical device recovery remains outside the product boundary.
04 / benchmark
Measure recovery with an open, format-specific harness
The companion open-recovery-benchmark repository freezes inputs, tool identity, healthy controls, evidence capture, and independent validators before a run. It reports PDF, JPEG, and PNG cohorts separately rather than inventing one cross-format percentage.
The released product repository also records an 18-case external-source holdout with exact content recovery across 6 PDF, 6 JPEG, and 6 PNG mutations. Both claims are bounded to their frozen corpora and validators; they are not a claim about arbitrary corruption.
05 / stack
Portable core, browser-native product surface
- browser host
- React 19, TypeScript, File System Access API, PDF.js
- preservation core
- C++20, WebAssembly, native filesystem adapter, streaming SHA-256
- format engines
- generated PRONOM/DROID V124 registry, libjpeg-turbo, qpdf, zlib-compatible PNG and ZIP recovery
- evidence
- independent raster and PDF validators, ZIP byte/CRC checks, JSON manifests
- benchmark kit
- Node.js filesystem harness, frozen corpora, guided browser captures, content-addressed evidence