“Scan a document” sounds like one button, but it can describe several different operations: capturing a page with a scanner, choosing an existing PDF or image, correcting the image, recognising text, and sending the result somewhere. A reliable browser workflow keeps those steps separate. It tells people what is happening, preserves the original when appropriate, and makes it clear when information is about to leave their device.
The distinction matters for both usability and privacy. A web page should not imply that it can quietly control every scanner connected to a computer. In ordinary browser workflows, the user scans with an operating-system tool or device app and then selects the resulting file. The browser receives only what the user chooses to provide.
Separate capture from file selection
A scanner is a hardware device with its own drivers, operating-system integration, and vendor-specific behaviour. The standard HTML file input is not a universal scanner-control interface. It gives a web application access to files the user explicitly selects, subject to browser security rules. That is a useful boundary: the page can process a selected document without gaining broad access to the user’s file system.
A clear interface can explain the two-step path: scan or photograph the document using a trusted device tool, then choose the resulting PDF or image. On a phone, a camera-based scanning application may create a PDF; on a desktop, the scanner utility may save a file to a folder. The site should not pretend those different systems behave identically.
Use the browser file APIs deliberately
An <input type="file"> control lets the user choose one or more files. The selected File objects expose metadata such as a name, type, and size, and can be read through APIs such as FileReader or modern blob methods. A local preview can help someone confirm that they selected the right page before uploading it.
const input = document.querySelector("#document");
const status = document.querySelector("#status");
input.addEventListener("change", () => {
const file = input.files?.[0];
if (!file) {
status.textContent = "No document selected.";
return;
}
const allowed = new Set([
"application/pdf",
"image/jpeg",
"image/png"
]);
if (!allowed.has(file.type)) {
status.textContent = "Choose a PDF, JPEG, or PNG file.";
input.value = "";
return;
}
status.textContent =
"Selected " + file.name + " (" + file.size + " bytes).";
});This is an interface example, not a security boundary. The browser-provided MIME type and file name are useful hints, but they are not proof that the bytes contain a safe document. A server that accepts uploads must validate the content independently, enforce size and resource limits, store files safely, and decide how long they are retained.
Make preview and correction understandable
Scanned pages are often imperfect. They may be rotated, skewed, too dark, cropped too tightly, or photographed with a shadow across the text. A preview should let the user inspect each page at a readable size and identify which page is being shown. If the application offers rotation or cropping, those controls should have clear names and should not silently replace the original.
For multi-page documents, show page count and page order. If a page is removed, make that action explicit and provide a way to undo it before the final upload. A progress indicator should distinguish local processing from network transfer: “Preparing page 2 of 5” is different from “Uploading page 2 of 5”.
OCR is a separate decision
Optical character recognition turns pixels into text. It can make a scanned document searchable and easier to quote, but it is not a perfect transcription. Small print, handwriting, unusual typefaces, low contrast, tables, and multi-column layouts can all produce errors. The interface should label recognised text as machine-produced and give the user a chance to review important values before relying on them.
OCR can be performed locally in the browser with a JavaScript engine such as Tesseract.js, or it can be performed by a remote service. Local processing can reduce the need to transmit document contents, but it may consume significant memory and processing time, especially on older phones. Remote processing may be faster or more capable, but it means the document is sent to another system. Those are product choices that deserve plain-language disclosure rather than a hidden implementation detail.
Treat privacy as part of the workflow
Documents can contain addresses, signatures, account details, school information, medical notes, or other private material. A site should explain whether processing happens locally, whether the file is uploaded, who can access it, and when it is deleted. If a user only needs to extract a few fields, retaining a full original document indefinitely is difficult to justify.
Do not upload a file merely because the user opened a preview. Make the transfer a distinct action, show the destination or purpose, and keep the selected file under the user’s control until they confirm. If the upload fails, preserve the local selection where possible and explain whether retrying will send the same file again. A progress bar that reaches 100 percent should not be confused with successful server-side validation or processing.
Validate on both sides
Client-side checks improve feedback, but the server remains responsible for security. A robust pipeline can inspect the actual file signature, allow only formats the application needs, reject malformed or oversized documents, limit page count and processing time, scan or quarantine suspicious files, and keep uploads outside executable web directories. Conversion and OCR should run with resource limits so a huge or malicious document cannot exhaust the service.
For a deeper treatment of the server side, see our guide to file upload validation as a pipeline. The key principle is the same: a file extension, a browser MIME value, or a successful transfer is not a complete validation result.
Design for errors and accessibility
Use a real label for the file input and explain the accepted formats before the user opens the picker. Report a rejected file next to the control, not only in a transient notification. If several pages are processed, identify the page that failed and offer a way to retry that page without restarting the whole document. Keep the original order visible, and do not communicate success or failure through colour alone.
- Explain how the document is captured before asking the user to select it.
- Show the selected file name, size, page count, and preview where possible.
- Separate local preparation, OCR, upload, and server processing states.
- Explain which operations happen on the device and which send data to a service.
- Validate the actual bytes on the server and impose resource limits.
- Give users a clear retention and deletion story.
References
MDN’s file input reference describes the browser’s file-selection control, while its File API guide explains how selected files can be read. The Tesseract.js project documents one browser-accessible OCR option. These references describe capabilities; the application’s privacy policy and upload architecture still need to explain what actually happens on a particular site.
A good document workflow does not hide complexity behind a single optimistic button. It breaks the task into understandable stages, keeps the user informed, and treats the original file as sensitive until the user knows where it is going. That makes the experience easier to recover from and much easier to trust.
What do you want to say about this?