manga-ocr: a Japanese OCR model built around the manga text bubble
Optical character recognition for Japanese text, with the main focus being Japanese manga
At a glance
- What is it?
- Manga-ocr is a Python package wrapping a Vision Encoder Decoder model trained for Japanese manga text. It recognizes vertical and horizontal multi-line text in one pass, and it will also invent text on a blank image.
- Who is it for?
- Adopt manga-ocr if you are building a Japanese reading or mining workflow and want a pip-installable model that reads a whole speech bubble in one forward pass. Do not adopt it if you need OCR on handwritten text, if you need bounding boxes and layout coordinates, or if you cannot tolerate a model that produces plausible Japanese on an image containing no text.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 59 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is the speech bubble, not the character
Most OCR pipelines assume text arrives as horizontal lines on a clean background. Manga breaks both assumptions. Characters are set vertically as often as horizontally, furigana sit in small type beside the main glyphs, dialogue is drawn directly over artwork, and the source images are frequently scans or screenshots at low resolution. A line-segmentation step that works on a scanned novel will cut a vertical bubble in the wrong place and hand the recognizer fragments that no language model can repair. Manga-ocr sidesteps that by recognizing multi-line text in a single forward pass, which the README presents as the main difference from many OCR models. The intended user is someone building a reading or dictionary-lookup workflow for Japanese manga, and the README points to Poricom and mokuro as existing consumers of the package. It can also serve as general purpose printed Japanese OCR, but that is a secondary use.
A Vision Encoder Decoder with a Japanese-aware decoder
The model is described as a custom end-to-end model built on the Transformers Vision Encoder Decoder framework. That means an image encoder feeding a text decoder, trained to emit the characters in the image rather than to detect and classify boxes. Because the decoder has some understanding of Japanese, the README notes, it can produce text that looks plausible even when the input does not support it. This is the same property that lets it repair damaged or low-quality glyphs, and it is the property that produces hallucinations. The training material listed in the acknowledgments is Manga109-s and CC-100. Manga109-s is a manga page dataset; CC-100 is a large raw-text corpus, which is consistent with a decoder that has seen a lot of running Japanese. Development code for training and for synthetic data generation lives in the manga_ocr_dev directory of the repository, so the data pipeline is inspectable rather than closed.
Installing it and calling it from Python
The package requires Python 3.9 or newer, with the caveat that the latest Python release may lag behind PyTorch support. Install with pip install manga-ocr, or uv add manga-ocr, or run it without installing via uvx manga_ocr. The Python API is two lines: construct MangaOcr() and call it with a path or a PIL image. The first call downloads roughly 400 MB of model weights, and the README says OCR is ready once the log prints OCR ready. On Windows, the documented failure is ImportError: DLL load failed while importing fugashi, which the README attributes to Python installed from the Microsoft Store and suggests fixing by installing Python from python.org. There is also a known workaround referenced for installing mecab-python3 on ARM. These are not edge cases to skim past: fugashi and mecab-python3 are Japanese tokenizer dependencies, and they are the parts most likely to break on an unusual platform.
Clipboard mode is the actual product for many users
Running the manga_ocr command with no arguments puts it into a background loop that watches the clipboard. Copy an image, and the tool replaces it with recognized text, which a dictionary such as Yomitan can then read. The documented chain is capture a region with ShareX or Flameshot, write the image to the clipboard, let manga-ocr convert it, and look the text up. On Linux, clipboard mode needs wl-copy under Wayland or xclip under X11, and the README gives echo $XDG_SESSION_TYPE as the way to find out which. There is a real cost to this mode: any image you copy is consumed and replaced by text. The README recommends folder scanning instead if you want normal image copying, using manga_ocr "/path/to/sharex/screenshot/folder" and a dedicated ShareX task that saves screenshots to a folder without touching the clipboard. That distinction between the two modes is the single most useful operational detail on the page.
It will invent text on a blank image
The README states plainly that the model always attempts to recognize some text, even if there is none, and that it might dream up realistically looking sentences. This is the limitation to design around. Any pipeline that feeds arbitrary crops into the model needs a way to reject output, and manga-ocr does not appear to provide a confidence score or an empty-result signal in the documented API. The README calls this something that might get improved in the next version, which is an admission rather than a fix. A second limitation is length: multi-line recognition is supported, but the README warns that the longer the text, the more likely errors become, and suggests running the model on a smaller portion of the image when a long passage fails. Handwritten text is explicitly out of scope. Anyone needing word-level bounding boxes for layout reconstruction is also in the wrong place, because the output is a string, not positioned regions.
How it differs from Tesseract and from a manga-specific pipeline
Tesseract is the obvious comparison and the difference is architectural. Tesseract performs layout analysis, segmentation and then per-line recognition, and it expects you to configure a page segmentation mode and a language. It has no model of what Japanese dialogue usually looks like, so a vertical bubble needs preprocessing before it has any chance. Manga-ocr skips segmentation and decodes a whole bubble, which is why the README can list vertical text, furigana and text over images as handled scenarios. The trade is control. With Tesseract you get boxes and can tune the pipeline; with manga-ocr you get a string and a model that will not tell you when it is guessing. The other comparison is mokuro, which the README lists as a tool that uses manga-ocr to generate an HTML overlay for manga. That is the right relationship to understand: mokuro is the page-level product, manga-ocr is the recognition engine underneath it. If you want an end-user reading experience rather than a library, mokuro is the thing to look at first.
Version cadence, licence and what to check before adopting
The releases show v0.1.14 in January 2025, then v0.1.15 and v0.1.16 in July 2026, so the project is still being touched but the version number has stayed in the 0.1 range throughout. That is a signal about API stability rather than quality: expect the surface to be small and mostly stable, but treat it as pre-1.0. The licence is Apache-2.0, which permits commercial use and modification and includes a patent grant; the model weights are downloaded at runtime from a Hugging Face hub, and the repository does not state a separate licence for them in the material available here, so verify that separately if redistribution matters to you. The training data acknowledgments name Manga109-s and CC-100, and anyone shipping a product should check the terms of those datasets rather than assuming the code licence covers the weights. Upgrading carries a real cost beyond pip: a new version can change model weights, which means re-downloading roughly 400 MB and re-validating output on your own pages, because there is no published accuracy figure to compare against. The README's example table is described as cherry-picked, so it is a capability demonstration, not a benchmark.
Editorial conclusion
Adopt manga-ocr if you are building a Japanese reading or mining workflow and want a pip-installable model that reads a whole speech bubble in one forward pass. Do not adopt it if you need OCR on handwritten text, if you need bounding boxes and layout coordinates, or if you cannot tolerate a model that produces plausible Japanese on an image containing no text. Before committing, install it and run manga_ocr on a blank PNG to see the hallucination behaviour for yourself, then run it on a page from the material you actually intend to process.
Community notes