# scribeocr: an OCR proofreading interface that runs entirely in the browser

> Scribe OCR is a free web application for three related jobs: adding a searchable text layer to a PDF, correcting OCR data produced by other tools, and producing genuine digitised books rather than scans with invisible text on top. The interesting engineering is the font optimisation that makes proofreading fast, and the split where the recognition engine lives in a separate repository.

**scribeocr/scribeocr** — Web interface for recognizing text, proofreading OCR, and creating fully-digitized documents. 

- Repository: https://github.com/scribeocr/scribeocr
- Website: https://scribeocr.com
- Stars: 810 · Forks: 46
- Language: JavaScript
- License: AGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/scribeocr-scribeocr

## Three jobs that share one proofreading interface

Scribe OCR is described as a free, in the readme's word libre, web application for recognizing text from images, proofreading OCR data, and creating fully digitized documents, and the readme says there are three primary use cases.

The first is adding an accurate searchable text layer to a PDF. The readme notes that it can be used as an alternative to applications like Adobe Acrobat for recognizing text and creating searchable PDFs, and that, unlike other tools, it makes it easy to correct errors in the recognized text.

The second is proofreading existing OCR data. It can be used to edit and correct OCR data created with other applications, including Tesseract HOCR files, and the reason it is faster than other methods is stated directly: by accurately positioning text over the input image, OCR data can be proofread significantly faster.

The third is creating fully digital versions of documents and books. Here the readme makes a sharp distinction. Other OCR programs do not truly digitize documents, but rather add roughly-positioned invisible text over the original image, whereas Scribe OCR can produce text native, ebook-style PDFs that accurately replicate the original document.

Those three cases share an interface, which is the reason the project is worth the attention it gets. The same proofreading view that lets you fix a few lines in a searchable PDF is the one that lets you digitise a two hundred page scan.

## The font optimisation is what makes proofreading bearable

Efficient proofreading is described as a major focus of the project, and the mechanism is specific.

To allow for efficient proofreading, Scribe OCR precisely prints editable OCR text over the source images. To replicate the document as closely as possible, it generates a custom font for each document, optimized using the provided OCR data.

That last sentence is the whole trick, and it is a good one. The problem with proofreading OCR is that the overlay text sits in slightly the wrong place, so your eye cannot align the word you are reading with the word in the image, and you correct the text more slowly than you would read it. By measuring the actual glyph shapes and spacing of the document and building a font to match them, the overlay lands where the ink is, and the alignment improves. The readme also notes that making errors more obvious can significantly decrease the time spent proofreading, and the readme puts a number on the payoff, bringing OCR data from ninety-eight per cent accuracy to one hundred per cent.

The readme includes a pair of screenshots showing the same text with and without the optimisation enabled, which is the honest way to make the claim, because the difference is a matter of whether the words line up.

The accuracy figure is worth reading carefully though. Going from ninety-eight to one hundred per cent is not the engine getting better, it is a human correcting the last two per cent faster. The value of the tool is in the time a proofreader spends, which is the opposite of the usual argument for a better OCR engine, and for a large book it is the argument that matters.

## Ebook mode against the invisible text approach

The readme uses a scanned book page from a public archive to show the three modes side by side, and the comparison is the clearest statement of what the project does differently.

The first panel is the original image. The second is the proofreading mode, which precisely layers colored OCR text over the source image. Most errors are also colored red, which indicates that the OCR engine flagged them as low confidence, so the eye is drawn to the places where the engine was unsure.

The third panel is the ebook mode, which contains only the text layer, now corrected. The readme explains the significance of that third panel: most OCR output formats either compromise on faithfully representing the original document, for example text or markdown that omits formatting, or produce enormous files by printing invisible text over the original scanned images. Ebook mode, by contrast, faithfully represents the original scan while maintaining a small file size.

One caveat is stated as well. Exporting PDFs with the traditional invisible text over image approach is also supported, for users who are only interested in proofreading and do not want a re-typeset document. So the project offers both outputs, and it is honest that the invisible text approach is the cheap one.

For a team digitising a collection, that distinction is the decision. A faithful ebook takes work and a proofreader, and produces a document you can reflow and search properly. The invisible text version takes a fraction of the effort and produces a large file that behaves like the scan it came from.

## The recognition engine is a separate project

The readme is clear about the division of the code, and it is the sort of thing that is easy to miss when you clone the repository.

This repository contains only the code for the user interface. Recognition is run using the Scribe.js library, which lives in its own repository, and the readme says discussion regarding recognition, from questions about quality to instructions on how to implement OCR within your own project, should happen in that repository.

So the two projects are the engine and the interface, and the interface is what this repository is. The topic list reflects that history, with hocr and tesseract named alongside ocr and proofreading, which are the formats and tools whose output this interface is built to consume and correct.

For a user, the practical consequence is where to file what. A question about why a page misread is an engine question and goes to the other repository. A question about the layout of the proofreading view is an interface question and goes here. The readme is also explicit that documentation for users lives at a separate documentation site and is managed in its own repository, so if the documentation is unclear or missing something, the readme asks for an issue in that documentation repository rather than in this one.

Three repositories for one product is unusual, and it works because the interfaces between them are clear: a library, a user interface, and the documentation.

## Running it locally, and the desktop application that does not exist

The Running section answers the question most people arrive with, which is whether they can use this on their own documents.

The answer is that the entire program runs in your browser and no data is sent to a remote server, and there is a public site if you do not want to run anything. But there is currently no standalone desktop application, so running locally means serving the files over a local HTTP server, and the commands are short:

```bash
git clone --recursive https://github.com/scribeocr/scribeocr.git
cd scribeocr
npm i
npx http-server
```

The recursive clone matters, because the repository uses git submodules, and the readme says the server command prints the address on your local network that the application is running on, so you can visit it from another machine on the same network. It requires npm, and the tooling is otherwise standard.

The absence of a desktop application is treated as an open question rather than a decision. The readme asks you to give a thumbs-up on a specific Git issue if you would prefer one, so that the maintainers can consider adding it. That is a small piece of evidence about how the project handles requests: a vote on an issue rather than a roadmap item.

The privacy property is the one to sit with. Because the recognition runs in the browser, a document never leaves the machine, and for the documents people scan, which are often confidential, that is the feature that makes the project usable in a setting where a hosted OCR service would not be.

## The test setup is unusual, and the licence is not

The package file describes a test setup that goes further than most web projects, and it explains how the project checks a browser interface.

The test command runs two suites in sequence, a module suite and a graphical user interface suite. The module suite starts the Karma test runner with a configuration file, and Karma is set up with launchers for both Chrome and Firefox, a Mocha adapter and a reporter, which is the standard way to run browser tests from a single command.

The interface suite is the interesting one. It uses Mocha directly against a tests directory, and it needs a real server: the start script runs a node server script from the tests directory, the wait script polls a local address until it answers, and the stop script shuts the server down over HTTP. Those three are orchestrated by a run-s invocation, and the whole interface suite runs in parallel with the server lifecycle. Selenium and Playwright are both in the dependency list, so the project is testing the interface with real browsers driven by two different tools.

The rest of the tooling is a careful JavaScript setup: ESLint with the Airbnb base configuration, plus plugins for imports and for documentation comments, and a jsconfig file for the editor. The package is an ES module, and the version in the manifest is 0.1.0, which is a detail worth noticing for a project with a live public site.

The licence is the other thing to notice. It is AGPL-3.0, and the author field is a team name rather than an individual. For a web application that runs entirely in the browser and that people are invited to self-host, that is a deliberate choice, and the readme's framing, that it is free and libre, matches it.

## Conclusion

Adopt Scribe OCR if you need to correct OCR output or to turn a scan into a real text document, and you are willing to do the work in a browser tab, because the whole application runs locally and nothing is sent to a server. Do not adopt it expecting a desktop application, since the README says there is not one yet and asks for a thumbs-up on the issue if you want one. Before you rely on the results, note that the recognition engine is a separate project, so questions about OCR quality belong in the Scribe.js repository, and check the output format you need, since the ebook-style PDF and the invisible text overlay are two different products with very different file sizes.

## FAQ

### What can Scribe OCR do?

Three things, according to the README: adding an accurate searchable text layer to a PDF as an alternative to applications like Adobe Acrobat, proofreading OCR data created by other tools including Tesseract HOCR files, and producing text native, ebook-style PDFs that accurately replicate the original document rather than invisible text over a scan.

### How does Scribe OCR make proofreading faster?

It prints editable OCR text precisely over the source image, and to replicate the document closely it generates a custom font for each document, optimized using the OCR data. The better the alignment, the faster the proofread, and the README says this can bring OCR data from ninety-eight per cent accuracy to one hundred per cent.

### Does Scribe OCR send my documents to a server?

No. The README says the entire program runs in your browser and no data is sent to a remote server, whether you use the public site or a local copy. There is a public site at scribeocr.com, and a local copy needs the files served over a local HTTP server because there is no standalone desktop application yet.

### Where is the OCR recognition code kept?

In a separate repository. The README says this repository contains only the code for the user interface, while recognition is run using the Scribe.js library, and that questions about recognition quality or about implementing OCR in your own project should be raised in that other repository. User documentation is managed in a third repository.

### How do I run Scribe OCR locally?

Clone the repository with submodules, install the npm dependencies and serve the files with a local HTTP server. The commands are a recursive git clone, a change into the directory, npm i and npx http-server, and the server prints the address on your local network that you can open in a browser.

## Sources

- [Issues](https://github.com/scribeocr/scribeocr/issues)
- [License: AGPL-3.0](https://github.com/scribeocr/scribeocr/blob/master/LICENSE)
- [Project website](https://scribeocr.com)
- [README](https://github.com/scribeocr/scribeocr/blob/master/README.md)
- [scribeocr/scribeocr on GitHub](https://github.com/scribeocr/scribeocr)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/scribeocr-scribeocr