Document imaging that runs in the browser.
Compress, convert, view, and reorganize documents entirely on the user's device. Images (JPEG, PNG, TIFF) and PDF go in; PDF, TIFF, or JPEG come out. Files are read into memory and processed in the page, no upload, no server round-trip, and it keeps working offline.
Five capabilities · one SDK, one API
Every method is async and resolves to the same response object; documents go in and out as byte arrays. Mix them freely in the same page.
Compression
Re-encode pages at a target DPI and color filter, then write a single PDF, a multi-page TIFF, or one JPEG per page. A0–A6 or a custom pixel layout.
Read more →Format conversion
Pass images (JPEG, PNG, TIFF) or PDF in; get a PDF, a multi-page TIFF, or per-page JPEGs out. Multi-page TIFF and PDF inputs are accepted and fan out page by page, so many files collapse into one document in a single call.
Read more →PDF & TIFF viewer
Render pages client-side. Stream one JPEG per page as it is produced, with index, total, and progress on every callback.
Read more →Page organizer
Merge documents, append pages onto an existing TIFF, and set page order by ordering the buffers you hand in.
Read more →OCR cleanup
Flatten a scan to a 1-bpp black-and-white TIFF in one call, bi-tonal output to hand to an OCR step.
Read more →The page never leaves the device
The SDK is compiled to WebAssembly and executes on the user's machine. That single fact changes the privacy story, the cost model, and the feel of the product.
No uploads
Documents are read into a byte array and processed in the page. Nothing is transmitted, so sensitive files never become someone else's compliance problem.
No per-page server cost
Processing runs on hardware you don't pay for or scale. There is no queue, no worker fleet, and no bandwidth bill that grows with page volume.
Works offline
Once the SDK files have loaded, no network is required. Field apps, kiosks, and branch machines on poor links keep processing documents.
Instant feedback
No round-trip means the result is there as soon as it is computed. Page streaming hands each page to your UI as it finishes rather than at the end.
Two run modes. The same API.
Pick one entry point per page. Both expose the same method names and the same response contract, switching is a change of import, not a rewrite.
Instant, in-page
Runs on the main thread. The simplest setup: one document at a time, small tools, quick utilities. A large job will block the UI while it runs, which is a fair trade when the job is short.
This mode also exposes a few extras: a page count straight from a File, EXIF-rotation toggles, and a reset to defaults.
Background, worker pool
Spawns a pool of workers and keeps the UI responsive. Built for bulk and parallel processing, fan a task out per file and await them together. Configuration setters broadcast to every worker.
Input buffers are transferred to the worker, so a buffer is detached on the caller side afterwards. Re-read the file if you need those bytes again.
Same contract in both modes
Every method is async and resolves to { STATUS, DESCRIPTION, DATA }. A failure never throws across the API, you inspect STATUS and read DESCRIPTION instead of wrapping calls in try/catch.
Files in, PDF out
const helper = new ImageWizHelper(); await helper.ready; await helper.initialize(LICENSE_BLOB); await helper.SetDPI(300); await helper.SetFilter(0); // Normal const buffers = await Promise.all( [...files].map(async f => new Uint8Array(await f.arrayBuffer())) ); const res = await helper.compressToPdf(buffers); if (res.STATUS) { save('out.pdf', res.DATA, 'application/pdf'); } else { console.error(res.DESCRIPTION); }
// every method resolves to this shape { STATUS: true, DESCRIPTION: "SUCCESS", DATA: … // shape per method } // compressToPdf, compressToTiff, ocrbw // → Uint8Array // compressToJPG // → Uint8Array[] (one JPEG per page) // inspect a document before you touch it const info = await helper.readImageInformation(buf); info.DATA.TOTAL_PAGES // 14 info.DATA.FILESIZE // KB info.DATA.INFORMATION // per page: // PAGE_NO, WIDTH, HEIGHT, // COLOR_TYPE, DPI
The same three lines start either mode, construct, await ready, then initialize. Which file you load decides whether the work runs in the page or across the worker pool.
Where this sits
The Browser JS SDK handles imaging on the device. When the work belongs on a server, at capture time, or behind a model, reach for a sibling line.
Document AI
Hosted APIs for full-text OCR, structured extraction, masking, and document analysis. For when you need to read a document, not reshape it.
Read more →Scanning SDK
Mobile and web capture for iOS, Android, React Native, and Flutter. AI-assisted capture with compression applied at the point of scan.
Read more →Compression SDK
The server-side library for the same imaging work, batch pipelines, back-office jobs, and anything that runs without a browser in front of it.
Read more →Questions developers ask first
STATUS, DESCRIPTION, and DATA. Failures never throw across the API, so there is nothing to catch, check STATUS, read DESCRIPTION for the message, and use DATA, which is populated on success only.File and the EXIF-rotation toggles, exist only in instant mode.file:// will not load the WebAssembly module. The loader resolves its companion files relative to its own URL, so keep them together in one directory. There is no backend to deploy and no infrastructure to scale.