In-browser SDK

An in-browser SDK is a software development kit that runs inside a web page, using the browser’s own capabilities rather than a native app or a server round-trip. For identity verification that means document capture and analysis happening in the browser tab the user already has open — no download, no install.

How it works

The technical story is what makes this possible at all. A browser is a constrained environment: no filesystem, no native libraries, and JavaScript that is an order of magnitude slower than compiled code for image processing.

WebAssembly removed most of that gap. Computer vision models compiled to Wasm run at near-native speed inside the tab, which is what allows document detection and analysis to happen client-side rather than by uploading frames to a server. WebGL and WebGPU add hardware acceleration where the device offers it.

Camera access comes through the MediaDevices API, which requires HTTPS and an explicit user permission prompt. That prompt is a real conversion event — some users decline it — and a flow that requests camera access without explaining why loses people at that moment.

Bundle size is the governing constraint, and it distinguishes serious implementations from careless ones. Everything the SDK needs is downloaded before the user can start, on whatever connection they have. A large bundle means a long wait at the exact point the user is deciding whether this is worth the effort. Model quantization, lazy loading and aggressive compression are not optimizations here; they are the difference between a usable flow and an abandoned one.

Processing on-device also changes the privacy position. If document analysis happens in the browser, the images need not leave it — which is a materially different data-protection story from uploading identity documents to a server, and one that matters in regulated contexts.

Why it matters for identity verification

The install requirement is where verification flows lose the most people, and an in-browser SDK removes it entirely.

A native app can do more — NFC chip reads, deeper camera control, better performance on old hardware. It also asks a user who came to open an account to first visit an app store, download, install, and return. A meaningful share never come back, and they skew toward the casual, legitimate applicants a business most wants.

The trade is real and worth naming. In-browser capture cannot read an ePassport chip, because browsers do not expose NFC for that purpose. It has less camera control, so auto-capture is harder to tune. Performance varies enormously across the device population. What it gains is that the user is already in the tab.

For most consumer onboarding that trade favors the browser. For a high-value flow where chip verification matters, native wins. The analysis itself is the same either way — what differs is what the environment can feed it, and Microblink’s verification workflow supports both so the choice is about the flow rather than the vendor.

In-browser SDK vs native SDK

The update row is underrated. A browser SDK ships a fix the moment it is deployed; a native SDK waits for store review and then for users to update, which in practice means supporting old versions for a long time.

What it can’t do

It cannot read an ePassport chip. Browsers do not expose NFC for document reading, so the strongest available document check — verifying the issuing state’s cryptographic signature — is unavailable in a browser flow.

It cannot guarantee consistent performance. The device population ranges from current flagships to five-year-old budget phones on poor connections. A flow tested only on good hardware will behave very differently in the field.

It cannot hide its logic. Client-side code is inspectable by anyone who opens developer tools. Thresholds, decision logic and anything security-sensitive belong on the server, with the browser handling capture and preprocessing.

It cannot bypass the permission prompt. Camera access requires explicit consent, and some users decline. That is a fixed cost of the channel, reducible with good explanation and not removable.

Frequently asked questions

What is the difference between an in-browser SDK and a native SDK?

An in-browser SDK runs in a web page using standard browser APIs and needs no installation. A native SDK is embedded in a mobile app, with fuller camera access, NFC chip reading and more consistent performance — at the cost of requiring a download.

Can an in-browser SDK read a passport chip?

No. Browsers do not expose NFC for document reading, so chip verification requires a native application. In-browser flows rely on optical document authentication and the machine-readable zone instead.

Does document processing happen in the browser or on a server?

It can be either. WebAssembly makes on-device processing viable, which means identity documents need not leave the browser — a materially different privacy position from uploading them, and one worth confirming with any vendor.

Why does SDK bundle size matter so much?

Because everything is downloaded before the user can begin, on whatever connection they have. A large bundle means waiting at the exact moment someone is deciding whether the process is worth completing.

Related reading

• Document capture — what the SDK is capturing, and why it is hard
• Identity document verification — the analysis the SDK feeds
• Liveness detection — the other half of a browser-based verification flow
• Biometric passport — the chip a browser flow cannot reach