Transparency
How ScanMaster works
ScanMaster runs 238 document and image tools, 224 of them fully inside your browser tab. This page is the mechanism behind that claim: what happens to a file from the moment you drop it to the moment it downloads again, which libraries do the work, and exactly where the browser model stops.
1. What happens when you drop a file
- The browser hands the file to the page through the File API. Nothing is transmitted: a
Fileobject is a handle to the bytes already on your disk. - The file is validated before it is read: not empty, not larger than 100 MB, an extension this tool accepts, and — the check most sites skip — a matching signature in its first bytes, so a file whose content contradicts its name is refused rather than fed to a decoder.
- The bytes are parsed by an open-source engine (listed below) and the result is built as a new
Blobin memory. - The page offers that blob as a download. There is no upload step to wait for and no job record to poll, because there is no job on a server.
- Object URLs created along the way are revoked when the component unmounts. Closing the tab discards everything the tool was holding.
2. The engines behind the tools
- pdf-lib and @cantoo/pdf-lib — writing PDFs: merging, splitting, rotating, page surgery, forms, watermarks, annotations, encryption.
- PDF.js — reading and rendering PDFs: page previews, text and table extraction, PDF to image.
- Tesseract.js — OCR: text recognition for scans and photos, in the tab.
- Canvas and the image codecs built into your browser — resizing, compression, format conversion, cropping, filters, background work.
- ExifReader — reading and rewriting image metadata.
- heic-to — decoding iPhone HEIC/HEIF photos, which no browser decodes natively on its own.
- jsQR, JsBarcode, qrcode — reading and generating QR codes and barcodes.
- docx, marked, fflate, utif2 — Word output, Markdown rendering, ZIP packaging of batch results, TIFF handling.
- Web Crypto — SHA-1 to SHA-512 digests, computed by your browser's own crypto layer.
They are the same libraries a desktop app would use, running in a sandbox instead of a native binary. That is the whole trick: the file never has to leave the machine it started on.
3. The one thing that does use the network
OCR needs language models. On the first OCR run in a browser, the recognition engine fetches its language data and WASM core from its own distribution and caches them locally; every later run works from that cache. The download is model data, not your document, and it carries nothing of yours with it. No other tool on the site makes an outbound request once the page has loaded.
4. Why some tools say “Coming soon”
14 of the 238 tools are labelled Coming soon. They are not a marketing list; they are jobs a browser tab honestly cannot do well yet:
- Converting Word, Excel or PowerPoint to PDF needs a real layout engine — LibreOffice on a server. A browser-side approximation produces documents that look close and are wrong in the places that matter.
- PDF linearization and deep optimization rely on native tooling such as qpdf.
- Web page to PDF needs a headless browser; a page cannot fetch another origin's rendered DOM, which is what CORS exists to prevent.
- Machine-learning background removal wants a GPU-served model. The browser-side tool that exists today uses colour and edge analysis and says so on its page.
Where a tool only partly works, its status is Partial, the limitation is printed on the page above the controls, and the FAQ repeats it. A page that describes only what works is advertising a different product.
5. How the text on each tool page is written
Every tool page carries an explanation, three steps, what you get, and questions with answers. Those steps name the controls that are actually on that page — the buttons are read out of the interface code, so a page cannot tell you to choose a quality slider that the tool does not show. The structured data on the page (the FAQPage and HowTo markup search engines read) is generated from the same source as the words you are looking at, which means the two cannot disagree.
Nothing on these pages is filler written to rank. Where a page was written by hand it is because the tool has a specific use worth describing; where the copy is assembled from the registry it is assembled from facts — accepted formats, output formats, the engine, the stated limitation — and we keep a list of which tools still need a human pass.
6. Check us
You do not have to take this page's word for it:
- Open a tool, press F12, go to the Network tab, then drop a file and run it. A request carrying your file would show up there with its size. For the tools marked ready, nothing does.
- Load a tool, then switch your machine offline and run it again. The work still completes — the engine was already on your machine. (OCR is the exception until its models are cached.)
- Read the source of any statement here against the limits in the interface: 100 MB per file and 50 files per batch are guardrails for browser memory, not a paid tier.
7. Devices and browsers
- Any current version of Chrome, Edge, Firefox or Safari, on desktop or mobile. The tools use standard APIs — File, Canvas, Blob, Web Crypto, Web Workers — and no plugins.
- The ceiling is your own memory, which is why the size and batch limits exist and why an enormous document is faster split into two runs.
- Camera tools need permission to use it, and only work over HTTPS — which is also why the site is served with HTTPS enforced.
8. Something wrong or missing
If a tool mislabels what it does, a step describes a control that is not on the page, or you think a job here should be possible in the browser and is not, tell us through the contact page. Bug reports change the code and the copy; the security page explains how to report a vulnerability, and the about page covers who is behind this.
Browse the full set from PDF tools or image tools — 13 categories in all.