Browser

The same C++ core, compiled to WebAssembly. 143 KB brotli.

Use the hosted tool at jvoltci.github.io/naina, or embed it.

Install

npm install @jvoltci/naina-wasm onnxruntime-web

Use

import { createReader } from '@jvoltci/naina-wasm';

const reader = await createReader({
  tier: 'tiny',
  modelBaseUrl: '/models',                       // see below, required
  onProgress: (done, total) => console.log(`${done}/${total}`),
});

const markdown = await reader.readMarkdown(rgb, width, height);
const page = await reader.readJson(rgb, width, height);

You must host the model weights yourself

modelBaseUrl is not optional in practice.

naina's registry points at GitHub release assets, which is correct for Python, Node and native builds, they make ordinary server-side requests. A browser cannot fetch them. A release download 302s to release-assets.githubusercontent.com, and neither hop sends an Access-Control-Allow-Origin header, so fetch is blocked by CORS.

Copy the files for your tier to somewhere you serve (same-origin is simplest) and point modelBaseUrl there. naina's core still sha256-verifies every file, so hosting them yourself does not weaken integrity.

app/scripts/stage-models.mjs in the repo does this, reading the file list from the core so it cannot drift.

Getting RGB bytes

naina ships no image decoder, the browser has one.

const bitmap = await createImageBitmap(fileOrBlob);
const canvas = new OffscreenCanvas(bitmap.width, bitmap.height);
const ctx = canvas.getContext('2d');
ctx.drawImage(bitmap, 0, 0);
const { data } = ctx.getImageData(0, 0, bitmap.width, bitmap.height);

const rgb = new Uint8Array(bitmap.width * bitmap.height * 3);
for (let i = 0, j = 0; i < data.length; i += 4, j += 3) {
  rgb[j] = data[i];
  rgb[j + 1] = data[i + 1];
  rgb[j + 2] = data[i + 2];
}

Decode at native resolution and let naina resize. If you scale with drawImage first, the result depends on the browser's scaling filter, the HTML spec leaves it implementation-defined, and Chrome, Safari and Firefox differ. naina's own resize is the same code on every platform.

Run it in a Worker

A full page takes one to two seconds. On the main thread that freezes the tab. naina's module is built for web,worker,node, so it loads in a worker unchanged.

// ocr.worker.js
import { createReader } from '@jvoltci/naina-wasm';

let reader;
self.onmessage = async ({ data }) => {
  reader ??= await createReader({ tier: 'tiny', modelBaseUrl: '/models' });
  const markdown = await reader.readMarkdown(data.rgb, data.width, data.height);
  self.postMessage({ markdown });
};

Offline

Model URLs are immutable and content-pinned, so a Cache API hit never needs revalidating. naina's runtime caches them under naina-models-v1.

Keep that cache separate from your app-shell cache and never version it with your build. Otherwise a CSS change evicts the weights and triggers a fresh multi-megabyte download.

Why the reads are async

ISession::run is synchronous C++, but onnxruntime-web's run() returns a Promise. Emscripten's ASYNCIFY suspends and resumes the WASM stack across that await, so the core stays unaware it is in a browser, which is why readMarkdown returns a Promise even though nothing inside naina is async.

The alternative, SharedArrayBuffer + Atomics.wait in a worker, needs COOP and COEP response headers. GitHub Pages cannot set headers, so it was not an option.

Execution providers

Defaults to ['wasm']. WebGPU is opt-in because it is currently broken in a way that is worse than a crash, it silently drops layout detection. See what it cannot do.

// Opt in only if you have measured it on your target browsers.
await createReader({ executionProviders: ['webgpu', 'wasm'], /* ... */ });

Accuracy vs native

Close, not bit-identical, and that boundary is documented with numbers.