Surya OCR 2.5: Local OCR Tested Across Languages and Documents
Surya OCR 2.5 runs locally and reads layout, tables, and text in many languages. Here's how it performs on real documents, warts and all.
What is Surya OCR 2.5?
Surya OCR 2.5 is an open source vision language model from Datalab that reads scanned documents and returns structured output: text, layout regions, reading order, and tables formatted as HTML. It’s built on a Qwen3.5-style architecture, runs locally on CPU or GPU, and is designed to handle multiple languages and mixed document types (invoices, forms, handwriting, stylized scripts) rather than just clean printed pages. It’s available on Hugging Face under the datalab-to/surya-ocr-2.5 model card.
TL;DR
- Surya OCR 2.5 is a small vision language model that outputs text plus layout, reading order, and HTML tables, and it installs locally with two pip commands and a Streamlit based GUI.
- It runs on modest hardware, using around 1,800 MB of VRAM in testing, and works fine on CPU without a dedicated GPU.
- On clean printed documents like an English invoice or an 1883 newspaper masthead, it got the core text right with only minor slips (a typo here, “November” misread as “Movember” there).
- It struggles with handwriting, stylized calligraphy, and fine print, badly garbling a handwritten Polish/French passport field and mangling a stylized Urdu book cover title.
- Table handling has a real weakness: in the invoice test it merged two visually separate tables (notes box and totals) into one structured table.
- Multilingual results were mixed: Hindi came out mostly clean, Arabic text was readable but merged across line breaks, and an unsupported language (Yoruba) still produced a surprisingly decent result.
- According to the model’s own size-versus-accuracy benchmark chart, Surya sits at the small end of the model size range but scores higher than most models of similar size, and higher than some larger ones too.
How do you install and run Surya OCR 2.5 locally?
Installation is lightweight by design. In the hands-on test, getting Surya running took two pip install commands followed by launching its bundled GUI, which is built on Streamlit. There’s no complex environment setup or custom server configuration required beyond that.
Hardware requirements are modest. The model consumed roughly 1,800 MB of VRAM during testing, which is low enough that a consumer GPU handles it comfortably. More notably, it can run entirely on CPU without issue, which matters for anyone who wants OCR without renting or owning a GPU. Processing speed per document in testing landed mostly under 10 seconds, occasionally stretching to 10-15 seconds for harder pages.
This combination (small footprint, CPU viability, simple install) is likely the main draw for developers who want OCR baked into a local pipeline without standing up GPU infrastructure or depending on a cloud API.
What does Surya OCR 2.5 actually output?
For each document, Surya produces three parallel representations: HTML, Markdown, and a block-level JSON. The HTML and Markdown outputs carry the recognized text along with structural cues like headers, paragraphs, and tables. The JSON output breaks the page into blocks with layout coordinates and reading order, which is useful if you need to programmatically map text back to its position on the page.
This matters more than it sounds. A model that returns a wall of correct text but can’t tell you where that text sits on the page, or what order it should be read in, is far less useful for downstream automation like form-filling, data extraction, or table parsing. Surya is explicitly built to handle that structural layer, with a separate small model dedicated to text line detection feeding into the main vision-language pipeline.
Where does Surya OCR 2.5 perform well?
On clean, printed material, it’s solid. An English invoice with a logo, address block, two tables, and a footer came back with correct line items, totals, and matching numbers, aside from one small typo. An 1883 newspaper masthead with decorative lettering and mixed fonts rendered its main title, tagline, and address accurately despite a low-resolution scan. A LaTeX manual page with body text, a section header, and a code listing kept the visible text and code block intact, with the header stacked properly in the layout.
A printed Hindi page from an old scan came out clean and readable, with correct punctuation and paragraph structure, despite Hindi scoring lower on the model’s own benchmark. Even a Yoruba document, a language not listed among Surya’s officially supported languages, produced mostly accurate text with only scattered errors, suggesting some generalization beyond its stated language list.
The size-to-accuracy benchmark chart on the model card backs this up: plotting accuracy against model size, Surya sits toward the small end but scores above most models of comparable size, and above a number of larger ones. A few bigger models still beat it outright, but for its footprint, the accuracy is strong.
Where does Surya OCR 2.5 fail?
The failures cluster around three things: handwriting, fine print, and stylized or decorative scripts.
A handwritten French letter with a printed header, date, signature, and an overlapping doctor’s stamp was mostly correct on the main message, but the stamp text came out partly wrong, its bounding box overlapped the signature, a stray Chinese character appeared in the output with no corresponding text on the page, and several characters rendered as a question-mark-in-a-diamond placeholder glyph.
A Polish document with handwritten name and address fields fared worse. The small handwritten lines were garbled badly, with a city name reading as an unrelated string of characters, and the error carried through consistently across the HTML, Markdown, and JSON outputs.
Fine print was another weak spot. On the 1883 newspaper, small-print text had specific misreads: “November” became “Movember,” “three pence” became something like “Thar spouse,” and “church food” came out mangled. On the LaTeX manual, the phrase “not points” was misread as “check mark not points,” a small error that changes meaning in technical documentation.
Stylized scripts hit hardest. A Urdu book cover with decorative Nastaliq calligraphy saw its title come out badly wrong and the author’s name lose letters entirely, while the model also inserted an English description of the artwork that wasn’t part of the original OCR target, and misread a faint watermark as a random URL. Arabic poetry with full diacritics was readable but merged separate verse lines into a single run, and the layout bounding box only captured the first three of six lines.
Is Surya OCR 2.5 worth using in production?
For clean, printed documents in reasonably well-supported languages, it’s a credible choice, especially given it runs on CPU and needs under 2GB of VRAM. The accuracy-to-size tradeoff looks favorable against similarly sized or even larger alternatives based on its own benchmark data.
But the testing surfaced a consistent pattern: accuracy degrades sharply as documents get harder. Handwriting, faint or small fine print, decorative calligraphy, and overlapping elements like stamps or watermarks all produced meaningful errors, not just cosmetic ones. The table-merging issue on the invoice, where two visually distinct tables were combined into one structured output, is the kind of error that would silently corrupt downstream data extraction if not caught.
The practical takeaway is to treat Surya as strong for triage and bulk processing of clean scans, but to add human review or a verification step for anything handwritten, stylized, or low quality before trusting its output in a production pipeline.
Frequently Asked Questions
What languages does Surya OCR 2.5 support?
It supports a range of languages including English, Polish, French, Hindi, Arabic, and Urdu, among others. Testing also showed partial success on Yoruba, a language not on its official supported list, though results there were less consistent than for supported languages.
How much hardware do I need to run Surya OCR 2.5?
Very little. It used around 1,800 MB of VRAM in testing and can run on CPU alone without a GPU, making it accessible on standard consumer hardware.
Does Surya OCR 2.5 handle tables and layout, or just raw text?
It handles both. Output includes HTML-formatted tables, a Markdown version of the document, and a block-level JSON with layout and reading order, in addition to the recognized text itself.
What types of documents cause the most errors?
Handwriting, faint or small fine print, and stylized or decorative scripts (like Urdu Nastaliq calligraphy) produced the most significant errors in testing. Overlapping elements such as stamps also confused layout detection.
Is Surya OCR 2.5 better than larger OCR models?
Not universally. According to its own size-versus-accuracy benchmark, it outperforms most models of similar size and beats some larger models, but a handful of bigger models still score higher overall. It’s best understood as strong for its size class rather than state of the art across the board.
