tesseract.js

Tesseract.js is a wrapper around the Tesseract OCR engine, compiled to WebAssembly so it can run entirely client-side in a browser tab or inside Node.js without a server-side dependency. It exposes a small worker-based API — createWorker, recognize, and an optional createScheduler for parallelizing jobs across multiple workers — that hides the complexity of spawning web workers or Node worker threads, loading language training data, and marshaling image data into the WASM module.

The project has been a long-running fixture of the JS OCR ecosystem since 2015, going through multiple major rewrites (v4 through v7) to cut bundle size, reduce memory usage, and simplify the worker API. It supports over 100 languages, common image formats (PNG, JPG, BMP, PBM) via base64 strings, URLs, or file paths, and can return not just plain text but word/line/paragraph bounding boxes, confidence scores, and hOCR/TSV output for downstream layout analysis.

What You Get

• A createWorker() API that spawns a browser Web Worker or a Node worker/child process pre-loaded with the WASM Tesseract core and the requested language data
• Support for 100+ languages, selectable individually or combined (e.g. 'eng+chi_sim')
• A createScheduler() job queue that distributes recognition jobs across a pool of workers for parallel throughput
• Structured output beyond plain text: per-word/line/paragraph bounding boxes, confidence scores, and hOCR/TSV/box-file formats
• Image preprocessing options (auto-rotate, grayscale/binary conversion) that can materially improve recognition accuracy
• Both Legacy and LSTM OCR engine modes (OEM), with LSTM as the modern default

Common Use Cases

• Client-side document scanning apps that need OCR without sending images to a server
• Browser extensions and bookmarklets that extract text from screenshots or web images
• Node.js batch pipelines that OCR scanned documents, receipts, or forms
• Accessibility tooling that reads text out of images for visually impaired users
• Prototyping OCR features before committing to a paid cloud OCR API

Under The Hood

Architecture

The library is split into a thin main-thread API (src/createWorker.js, src/createScheduler.js) and a worker-side script (src/worker-script/index.js) that actually loads the compiled Tesseract WASM module and drives recognition; the two communicate over a small message protocol keyed by workerId/jobId/action built in src/createJob.js, so every operation (load, loadLanguage, recognize, FS filesystem calls) becomes an async job resolved by matching response messages back to pending promises. Browser and Node environments are unified through a single import path (src/worker/node vs src/worker/browser, swapped via package.json’s browser field) each implementing the same spawnWorker/send/onMessage/terminateWorker contract, so createWorker.js and the worker script itself are written once and run unmodified in either environment. createScheduler.js adds a simple FIFO job queue over a pool of workers, dequeuing to the first idle worker — a deliberately minimal scheduler rather than a full task-graph system.

Tech Stack

Core recognition comes from tesseract.js-core, a separately published WebAssembly build of the C/C++ Tesseract engine, invoked here through Emscripten’s generated JS glue. Supporting dependencies handle format-specific concerns: bmp-js for BMP decoding, is-url for input-type detection, idb-keyval for caching downloaded language traineddata in IndexedDB (browser) or on disk (Node), zlibjs for gzip decompression of traineddata files, and wasm-feature-detect to pick SIMD-capable core builds when available. The build pipeline uses Webpack (browser UMD bundle) and Rollup (ESM build) with Babel for transpilation, and ships both dist/tesseract.min.js (CDN/script-tag) and an ESM entry point.

Code Quality

Tests run via Mocha (tests/*.test.mjs) against a running dev server for Node, plus Karma for browser-driven tests, covering format support (BMP/JPG/PNG/PBM), base64 input, Legacy vs LSTM OEM output, orientation-corrected images, and the scheduler’s job distribution — a reasonably thorough behavioral suite given the project’s surface area, though it is not type-checked (plain JS with a hand-written .d.ts) and coverage of internal worker-script error paths is thinner than the happy-path recognition tests. ESLint (Airbnb base config) and a GitHub Actions CI workflow (lint + Node/browser test matrix, CodeQL scanning) run on every push, and commits_per_month in the current snapshot is low, consistent with a mature, slow-moving-but-still-maintained project rather than one under active rewrite.

What Makes It Unique

Unlike most JS “OCR” packages that proxy to a cloud API, Tesseract.js runs the actual Tesseract recognition model fully client-side via WebAssembly — no network round-trip, no per-request billing, and it works offline once language data is cached. Its worker abstraction is also unusual in unifying browser Web Workers and Node worker threads/child processes behind one API surface, so the same createWorker/recognize call sites work unmodified in either runtime, which is the main reason it has remained the default choice for in-browser OCR since well before most alternatives supported WebAssembly at all.