From a document photo to an upload-ready PDF.

The problem

A file picker does not prepare a document.

A document-upload form may expect a PDF below a specific byte limit, while the person using it has photos of paper. The gap includes importing or capturing images, correcting perspective, organizing pages, and fitting the result within the upload requirement. The result also needs to remain inspectable before it is submitted.

ScanFit handles that preparation in the browser. It returns a PDF File to the host application after the user reviews it. The host remains responsible for attaching the file to a form or uploading it; scanning and submission are separate steps.

My responsibility

My part: the library and its integration surface.

I created ScanFit as an open-source TypeScript library with a framework-independent core and optional React components. The core manages document-processing sessions. React components provide the ready-made scanner experience, with customization and headless integration options for applications that need their own interface.

The workflow supports importing supported image formats or capturing pages, correcting document corners and perspective, reviewing pages, and exporting against an explicit byte limit. The public repository, npm package, and hosted demo make this work available for inspection. It is a public alpha rather than a release-certified beta.

Implementation & tradeoffs

Make constraints part of the result.

Document processing runs locally, with worker-based processing and browser canvas facilities. This avoids a document-processing upload service in the library’s default workflow. The tradeoff is dependence on browser capabilities and available memory, and the host page and its third-party scripts still need to be trustworthy.

An export request includes an exact maximum byte count and quality limits. A result can be ready, cannot-fit, or cancelled. The cannot-fit outcome is important: meeting a file-size requirement must not silently mean violating the specified quality floor. The application receives an explicit outcome it can explain to the user.

The review step shows the page previews associated with the export before the file is accepted. This gives the user a chance to inspect the processed document. The framework-independent core keeps the session and processing model separate from the optional React presentation, at the cost of more integration work for a fully custom interface.

Scope & limits

Public code, with the alpha boundaries visible.

The public alpha is published and has a hosted demo. Start with synthetic sample documents when exploring it. The workflow illustration on this page explains the processing stages; it is not a screenshot of the application. The live demo and source links are the places to inspect the working implementation.

Physical-device testing, broader document fixtures, and user pilots remain release gates in the repository. Detection can be wrong, and some inputs cannot fit the requested limit. The library does not provide OCR, existing-PDF import, searchable text, or persistent document storage. Refreshing or closing the browser loses unfinished work. These limits are part of the current product scope, not hidden behind a general reliability claim.