eSearch: a Linux-first screenshot tool that reads the text on your screen

What eSearch actually does, and who it is for

The README frames the project as an Electron rewrite of an earlier app called Information-portal, built to bring something like Smartisan Big Bang or MIUI Portal to the desktop: select text on screen, then search, translate or copy it. The author's stated motive is Linux, a platform where the Windows screenshot tool Snipaste did not run at the time and where Flameshot, in the author's view, lacked a comparable color picker.

The feature list is long because the project kept absorbing adjacent jobs: rectangular capture with crop, color picker, freehand brush, shapes, mosaic and blur; scrolling capture that stitches horizontally, vertically or in any direction; screen recording including webcam and keystroke hints; pinning a screenshot to the screen as a floating window with zoom, opacity and mouse pass-through; offline OCR; image search against Google, Baidu and Yandex; translation through free engines or your own API keys; and a screen translation mode that replaces text in a pinned image with the translated text on a timer.

The audience is narrower than that list suggests. Someone who takes five screenshots a month does not need this. Someone who reads documentation, error messages or subtitles in a language they do not speak, and who does not want to paste screenshots into a web service, is the person the offline OCR and screen translation exist for.

How the capture, OCR and translation pipeline fits together

The repository is a TypeScript Electron application. The top level separates lib/, src/, script/ and test/, with electron.vite.config.ts driving the build and electron-builder.config.js driving packaging. package.json declares esearch-ocr at 8.5.2 and esearch-seg at 1.1.9 as dependencies, plus onnxruntime-node, node-screenshots, fabric, and mediabunny for media work.

That dependency set tells you the shape of the data flow. Capture happens in native code through node-screenshots rather than through browser APIs, which the README calls out directly: screenshotting depends on the local system and browsers cannot do it. The captured bitmap then goes to the OCR path, where esearch-ocr and onnxruntime-node run a PaddleOCR-derived model locally, with esearch-seg handling segmentation. Text comes back, and translation is a separate stage that can call a free engine, a configured API such as DeepL or Baidu, a hosted AI model, or a local model.

The offline part is the interesting design decision. The README states the OCR ships ready to use out of the box, with a large character set and support for rare characters and symbols, but notes that the v5 model and additional languages (Chinese, English, Korean, Japanese, Telugu, Kannada, Tamil, Latin, Arabic script, Cyrillic and Devanagari) must be downloaded in settings. So the default install is offline-capable, but multilingual offline work is a second download you have to remember. The README also documents online OCR through Baidu and Youdao as an alternative, and a punctuation-based segmentation algorithm as an alternative to paragraph recognition.

Installing eSearch and taking a first screenshot with OCR

The README points to the project site's download page and to the GitHub releases tab, where you pick the package for your system. On Arch Linux the AUR packages are e-search and e-search-git. On Windows, winget is supported. The README states there is no Homebrew package yet.

winget install esearch

After installing, launch eSearch from your launcher. The README says it will appear in the tray, and the default hotkey is Alt+C, configurable in settings.

Once running, the basic OCR loop is: press Alt+C, drag a rectangle over the text you want, and press Enter. The README describes this as the out-of-the-box offline OCR path. If you want the capture to run OCR automatically without the extra keypress, the README states you can configure a custom action to execute immediately after selection, such as automatic OCR.

Two platform notes from the README worth knowing before you start. On Windows, most installs will prompt you to download a dependency library needed by the screenshot component; the prompt opens a Microsoft download page, and a restart may be required afterwards. On Gnome, the tray will not respond until you install the appindicator support extension.

If you want to build from source instead, the README gives these commands:

git clone https://github.com/xushengfeng/eSearch.git
cd eSearch
npm install
npm run dist

The README states the build output lands in a build directory containing an installer and an unpacked directory. For development it lists npm run start to run and npm run dev to debug. Note that package.json declares [email protected] as the package manager and the repository ships pnpm-lock.yaml, so the npm install line in the README is worth double-checking against your environment.

Where eSearch gets in the way: install size, platform gaps and version drift

The README answers the install-size question before you ask it. Besides Electron itself, the package carries the onnx runtime for AI models, the offline text recognition models, a portrait recognition model for recording, an object removal model for advanced editing, and FFmpeg for recording format conversion (not bundled on Linux, where the README says a system library exists). The author's own justification is that the extra weight buys features a few dozen lines of JavaScript could not.

That is a real trade-off, not a flaw to paper over. If your only need is a rectangle and a save button, eSearch is the wrong tool, and the README effectively says so by describing the storage cost plainly. The same applies on very old systems: the README states Windows 7 and Windows 8 are no longer supported because Electron dropped them, and that self-compiling is possible with the caveat that some features may not work.

Version drift is the failure mode the README admits to most directly. Upgrading can produce errors that did not exist before, which the README attributes to incompatible configuration between versions, and the suggested fix is Settings, Advanced, Advanced Settings, then restore default settings. If that does not resolve it, the README points to filing an issue. There is no documented rollback or config migration path, and the README does not describe one.

macOS has its own rough edge: the README notes that macOS restricts dmg files downloaded from the internet and that users see a file-is-damaged message, with the workaround varying by system version and left to a web search.

eSearch versus Flameshot and Snipaste

The README names both alternatives and explains why the author moved on. Snipaste is described as a good Windows screenshot and pinning tool that did not support Linux at the time. Flameshot is described as the Linux choice that lacked an intuitive color picker.

The difference in approach is architectural. Flameshot is a native Qt application that captures and annotates; Snipaste is a native Windows tool built around screenshot plus pin. Neither is designed around reading the text inside the pixels. eSearch is an Electron application whose central loop is capture, recognize, then act on the recognized text, whether that means searching, translating, or writing the translation back over a pinned image. The screenshot editor is the entry point, not the product.

That also explains the size difference and the platform requirements. A native capture tool has no OCR runtime, no ONNX models and no FFmpeg inside it. If your problem is annotation and sharing, a native tool will be faster to start and smaller to install. If your problem is that the text you need is inside an image and in a language you cannot read, eSearch is doing work the other two were not built for. The README also lists online OCR and third-party translation APIs as options, so you are not locked into the local model path if it underperforms on your content.

Maintenance, licence and what upgrading costs you

The repository is not archived, and the last push was on 2026-09-15. Recent releases listed are 15.5.1 on 2026-09-13, 15.4.2 on 2026-08-18 and 15.3.4 on 2026-07-30, which is a steady cadence across roughly six weeks. The README states the project has been through several rounds of version iteration, and the test notes list Arch Linux with KDE Plasma on Xorg, Windows 10 and Windows 11, and macOS Catalina as tested configurations.

Upgrade cost is mostly configuration risk. The README's own troubleshooting entry for post-upgrade errors points at incompatible settings and recommends restoring defaults, which means an upgrade can cost you your custom hotkeys, translation engine keys and OCR preferences. There is no documented migration or export step, so if you have invested in configuring multiple translation engines or custom AI endpoints, expect to redo some of it after a major version change.

eSearch is licensed GPL-3.0. If you redistribute it or ship a modified build, the copyleft terms apply to the whole work, and the README's own note that users can self-compile for unsupported platforms puts that scenario in scope. This is a description of the licence, not legal advice; check with your own counsel before bundling it into a product.

Editorial conclusion

Adopt eSearch if you work on Linux and want screenshot plus offline OCR plus translation in one tray application, and you accept an Electron-sized install with bundled models and FFmpeg. Skip it if you need a lightweight native tool, a Homebrew package (the README says there is none yet), or Windows 7 or 8, which Electron no longer supports. Before relying on it, confirm two things on your own machine: that the appindicator extension is installed if you run Gnome, and that the OCR language models you need are actually downloaded in settings, since the README states extra languages and the v5 model are separate downloads.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. xushengfeng/eSearch on GitHub