jina-ocr-v1: One OCR model for layout, tables, math and 100+ languages

Get hands-on with Elasticsearch: Dive into our sample notebooks in the Elasticsearch Labs repo, start a free cloud trial, or try Elastic on your local machine now.

jina-ocr-v1 is Jina AI by Elastic’s new preprocessing model for text scans, text-rich image data, fully rendered print pages, and other printed materials in digitization-resistant formats. It’s an end-to-end document parser, understanding document structures from their visual layout and using AI to process raw image data into useful, structured text for indexing and further processing. It turns scanned pages, photographed documents, slides, and handwritten notes in over 100 languages into structured, machine-readable text, with a single call to an AI model.

Optical character recognition (OCR) has been a goal of AI for a long time, and in some simple cases (such as straightforward layouts, crisp images, standard fonts, and highly resourced standardized languages), reliability can be very high using inexpensive conventional software. But real data is messy. Scans and photos of documents are often blurry, and images are compressed and quality varies. Plus, page layouts can be complex. And these examples don’t even take into consideration handwriting and global languages.

A vision-language model trained for OCR

jina-ocr-v1 is a vision-language model (VLM) with specialized training. Unlike all-purpose large language models (LLMs), it doesn’t answer questions. It’s trained to do one thing: output the text in an image in a coherent order matching how humans would read the image, preserving what’s important about the content’s visual structure.

This integrates into one model a feature set that otherwise requires a pipeline of multiple models and specialized programs to implement, including:

• Layout-aware document processing that produces Markdown format output, retaining as much of the structure of the original document in its text output as possible.

• Support for over 100 languages, with all major international languages and scripts represented.  

• Handwriting recognition, including block text in a wide array of languages and English cursive.

• Table extraction into basic HTML format, suitable for further processing and importing into spreadsheets or other applications.

• Math recognition, turning printed images of formulas into LaTeX math code that you can insert directly into any document engine or scientific software that supports LaTeX.

jina-ocr-v1 has a total of 3.4 billion parameters, but because it uses a mixture-of-experts architecture, it only uses a part of the model at any one time. Only 570 million parameters, about a sixth of the total, get used when responding to user input, but exactly which 570 million is determined dynamically at inference time. This means jina-ocr-v1 takes up as much memory as any other 3.4 billion parameter model, but runs as quickly as a 570 million parameter one.

jina-ocr-v1 specifications

How the jina-ocr-v1 architecture builds on DeepSeek-OCR

The full jina-ocr-v1 model is a 3.4 billion (3.4×10⁹) parameter mixture-of-experts model with 570 million active parameters. It’s based on the encoder-decoder architecture of DeepSeek-OCR with the addition of FastMTP, which reduces computational load at inference time by predicting multiple output tokens at once. This approach results in more efficient processing, with lower latency and less resource consumption at inference time.

Figure 1: The architecture of jina-ocr-v1.

For more information about the model’s architecture, see the technical report and jina-ocr-v1’s model page on Hugging Face. 

Input formats and resolution limits

Following the DeepSeek-OCR architecture, images are resized to 1024x1024 and processed into 256 input tokens for the text decoder. To incorporate additional detail, the image is also processed into up to nine additional cropped higher-detail image tiles, depending on the resolution and geometry of the image, with each reprocessed into up to 100 additional tokens each. Very large images with features too small to make out at 2048x2048 resolution will probably not be processed correctly.

jina-ocr-v1 automatically supports all common image formats. However, it doesn’t have native support for PDFs. You’ll need to convert your PDF pages into an image format (we recommend PNG with minimal compression) for use with jina-ocr-v1. A variety of open source and commercial utilities can perform this task.

For more details on input processing, see the technical reports for jina-ocr-v1 and for DeepSeek-OCR.

Output formats: Markdown, HTML tables, and LaTeX math

jina-ocr-v1generates text with Markdown formatting, supporting only the basic syntactic elements most compatible with different Markdown implementations. Markdown supports common text structure information, like sections and lists, in a simple, human-readable format. It’s readily converted into HTML and other rich text formats.

The model departs from basic Markdown to encode tables and math formulas. Specifically:

• Tables are encoded in basic HTML format, using <table>, <th>, <tr>, and <td> tags, without CSS or other stylesheet information.

• Formulas are encoded in LaTeX math mode syntax, with the commands available in the amsmath package.

Pushing the boundary of performance and cost

jina-ocr-v1 scores among the top models on olmOCR-bench and is the best model overall with less than 600 million active parameters. It sits on the Pareto frontier for AI OCR models, meaning that all the models that perform better on this benchmark have more active parameters, taking more computing power and resources than jina-ocr-v1.

Table 1: jina-ocr-v1 among olmOCR-bench top performers.

Figure 2: jina-ocr-v1’s place at the Pareto (performance vs size) frontier on the olmOCR-bench test suite. Only much more compute-intensive models have significantly higher published scores.

OmniDocBench (Table 2) offers a more mixed picture, but jina-ocr-v1 scores highly among specialized OCR models adapted from VLMs. However, a comparison of Table 1 and Table 2 reveals that there are no models of comparable size that beat jina-ocr-v1 on both benchmarks, showing that its high performance is robust across different task types.

Table 2: jina-ocr-v1 score on OmniDocBench compared to selected top specialized VLM models.

Table 3 compares jina-ocr-v1 to vision-enabled, nonspecialized LLMs. It significantly outperforms GPT-5.2 and the largest Qwen3 VLM on OmniDocBench, while coming close to Gemini 3 in overall score.

* TextEdit and Read OrderEdit benchmarks are scored so that a smaller value is better than a higher one.

Table 3: jina-ocr-v1 scores compared to top general-purpose LLMs pressed into OCR tasks. 

As shown in Table 3, on OmniDocBench tests focused on correct reading order and overall character-level accuracy (TextEdit and ReadOrderEdit),  jina-ocr-v1 beats all three frontier LLMs handily. Only Ovis2.6-30B-A3B scores higher in all areas in OmniDocBench, at almost nine times as many total parameters and roughly six times as many active parameters.

To test on your data, you can try it out on the Jina AI website, or read the section Five ways to access the jina-ocr-v1 OCR API to see how to integrate it in your document processing and search pipeline.

Layout-aware end-to-end document parsing

OCR has been around for a long time, long enough that many people have experienced struggling with its shortcomings. It’s not that it’s so hard to recognize letters on the page, especially if clearly imaged and using a modern digital font, it’s that recognizing letters in a left-to-right sequence is only the first step to making sense of what’s printed on a page. 

Consider the image below, extracted from the print edition of the June/July 2024 UK edition of Cosmopolitan magazine:

Figure 3: Image extracted from page 17 of UK Cosmopolitan, June/July 2024, from the Internet Archive.

Simply reading from left to right will produce a chaotic, unreadable, useless text, even if every word and letter is recognized correctly. A good OCR model has to parse the image, recognizing, like a human does, the individual elements in relation to each other, and reading the text as intended, attending to fonts and spatial organization.

It should also recognize elements that don’t belong in its output. A page may contain images that incidentally have text in them, like the book covers in Figure 3. There’s also often header and footer information that isn’t part of content, like page numbers and boilerplate. It’s difficult to filter those elements out after OCR, so recognizing and removing them has to be a part of preprocessing or the OCR process itself. 

Figure 4 shows how jina-ocr-v1 parses the image in Figure 3, including elements to ignore. Each colored block indicates text elements that belong together, containing text and possibly other blocks, while the images of books are marked out because, while they do contain text, that text doesn’t belong in the OCR output. 

Figure 4: The same print page but parsed into elements that an OCR process has to take into account and the ones it should ignore.

These problems mean that OCR for materials with complex layouts has traditionally been a multistage process, using different algorithms to:

1. Break up the page.

2. Identify the role of each part of the image.

3. Recognize the text with the help of a statistical language model.

4. Reassemble the result for output.

Each stage is fragile, and errors accumulate through the processing pipeline. 

Instead, end-to-end document parsing does all that in a robust, single-pass generative language process.

jina-ocr-v1 handles this kind of visually complex document with ease, as shown in Figure 5, not only capturing the words, but ordering them correctly, preserving structural information about titles and sections, and ignoring the text in the pictures of books as well as the non-content header and footer.

Figure 5: jina-ocr-v1 output in Markdown format, from processing the image in Figure 3.

jina-ocr-v1 does more than just identify the letters on a page. It manages complex structural information and supports over 100 languages. It also returns information in a Markdown-style format that’s both human-readable and widely supported out of the box by downstream applications.

Table extraction to HTML

Identifying and extracting tables sounds simple, but it’s very challenging to do well without an AI model. 

As an example, consider this table from a recent Jina AI conference paper:

Figure 6: A rendered table, originally composed in LaTeX, from a formal conference paper. 

OCR software that lacks table awareness would likely produce a result like this:

Model AI2D Chart Text Doc Info OCR SEED CharXiv Avg
QA VQA VQA VQA Bench 2+ (RQ/DQ) 
jina-vlm 82.0 81.9 83.2 90.6 71.6 778 67.2 32.3/63.5 72.3
Qwen3-VL-2B 76.9 77.2 79.5 92.3 71.9 858 67.3 28.8/62.3 71.6
IVL3.5-2B 78.8 80.7 76.5 88.5 69.3 836 68.0 31.6/65.0 71.6
IVL3-2B 78.6 80.2 77.0 87.4 67.1 835 64.6 28.3/54.7 69.2
Qwen2-VL-2B 74.7 73.5 79.7 89.2 64.0 809 62.4 23.3/55.0 66.4

This is useless as a table without further processing. But, when presented with the same table, jina-ocr-v1 produces clean, minimalist HTML:

Figure 7: HTML generated by jina-ocr-v1 for the table image in Figure 6. Some whitespace has been removed for compact display.

This HTML yields a functionally identical table that’s suitable for display, reading into spreadsheets or other applications that support tables, or other further processing.

Figure 8: The HTML in Figure 7, rendered in a browser. Visible borders were added via a stylesheet for clarity. 

When tables appear inside a page with other text, the HTML tables are inserted into the Markdown output, as in Figure 9:

Figure 9: An example document page containing a table (left), and the rendered Markdown output, including HTML table, with visible borders added via CSS for clarity (right).

Math recognition: Printed formulas to LaTeX

Mathematical formulas are visually complex and nonlinear, full of shapes that look like ordinary printed language, but cannot be processed like ordinary language. jina-ocr-v1 has special training to recognize and transform printed math into LaTeX math code. 

Figure 10 is an image of a block of formula-rich text extracted from a recent Jina AI conference paper:

Figure 10: An extract from a scientific paper (left), and jina-ocr-v1’s raw output from processing that image (right). The parts between “$” characters are LaTeX math.

After pasting the generated output from Figure 10 into a fresh LaTeX document (with \usepackage{amsmath}) and compiling it to printable form, the result is functionally identical, missing only the block-level equation alignment present in the original:

Figure 11: jina-ocr-v1 LaTeX formula output, recompiled as LaTeX. Some block alignment information is lost, but the math formulas are all intact and correct.

Handwriting recognition: Print and cursive

jina-ocr-v1 handles both print and cursive handwriting:

Figure 12: A 1941 handwritten letter to US President Franklin D. Roosevelt from a child, preserved in the FDR Presidential Library (left), and jina-ocr-v1's output for it (right). Note that the cursive archivist’s mark in the upper right-hand corner, written in a completely different hand, proves too hard to manage with so little context.

Cursive handwriting is highly varied, and even human readers may struggle with it. While jina-ocr-v1 performs well on neat cursive English, messy writing is as hard for it to read as for humans. When writing is sloppy, poorly captured by OCR, or otherwise difficult to decipher, jina-ocr-v1 can perform quite poorly.

For example, the handwriting below is from the famous children’s books illustrator Beatrix Potter:

Figure 13: A letter from Beatrix Potter to a child acquaintance (top), and the extracted text (bottom).

jina-ocr-v1 is able to accurately capture the flowing cursive in Figure 13, even when it wraps around Potter’s drawings of mice. However, the place-name at the top is much less cleanly written and lacks disambiguating context, resulting in errors. Even the human reader likely finds it difficult to read.

OCR for slides, reports, labels, and business cards

jina-ocr-v1’s expanded training for complex layouts makes it work well with unconventional materials. The examples below show some of the scope of the model’s abilities.

Presentation slides

Figure 14: A slide from Elastic NV’s most recent quarterly financial presentation (left), and jina-ocr-v1’s output, rendered via HTML (right). Note that the model correctly extracts the hierarchy of titles and headings and associates each text with the proper heading. It also ignores the page number and boilerplate Elastic logo.

Business reports

jina-ocr-v1 processes the visually dense pages of corporate business reports, such as in Figure 15:

Figure 15: Page 2 of the SpaceX quarterly earnings report for Q2 2026 (August 4, 2026) (left), and the rendered jina-ocr-v1 output for it (right). jina-ocr-v1 is aware that “Countries with Starlink Coverage” goes with “167,” even though a simple column-based reading wouldn’t have made that association.

Glossy business reports and presentations often have complex, visually interesting layouts that make them hard for traditional OCR to correctly process. `jina-ocr-v1` excels at these kinds of materials, like the example in Figure 16 below:

Figure 16: Page 2 of the 2025 Integrated Report from the Japanese Meiji Group (top), and an HTML rendering of jina-ocr-v1’s output (bottom). Note how the visual hierarchy of elements in the original is preserved in the Markdown output.

Labels and packaging

jina-ocr-v1 can read print from labels and graphic design materials. This is especially helpful with high-information content materials, like medical packaging:

Figure 17: A drug packaging image from the US government’s DailyMed website (top), and the extracted text rendered from Markdown to HTML (bottom).

It works just as well with more conventional consumer goods labeling and photos, if the image quality is high, as in Figure 18:

Figure 18: A common household product with text on the label (left), and extracted output rendered as HTML (right).

Business cards

jina-ocr-v1 has no difficulty with visually compact documents, like business cards:

Figure 19: A photo of a business card sourced from Wikimedia Commons (left), and the HTML rendered text result (right). Note how the three-level header hierarchy is preserved and how jina-ocr-v1 correctly understands the alphanumeric structure of Canadian postal codes, correctly inserting “1” and “0” (instead of “I” and “O”) into “K0K 1Z0.”

Multilingual OCR across 100+ languages

jina-ocr-v1 has been trained in over 100 global natural languages. It performs high-quality OCR for a diverse range of global media, without additional modules to support different language or writing systems.

Diacritics and modified Latin alphabets

Single-language OCR software (especially for English) often struggles to render diacritical marks on letters. Most languages use them, and failing to accurately render diacritics can make indexing, information retrieval, and other downstream applications fail.

Even in Western European languages, like French and German, modified letters like the c-cedilla (Ç) and Eszett (ß), pose well-known problems for many OCR suites:

Figure 20: jina-ocr-v1 handling a French c-cedilla (Ç) and a German Eszett (ß) together in a single image (left), with the plain text Markdown result (right).

Figures 21 and 22 show jina-ocr-v1 handling Czech and Turkish, which are languages written with heavily modified Latin alphabets that use diacritics pervasively:

Figure 21: COVID-19 information from the Czech government, in the original PDF (left), and jina-ocr-v1’s Markdown output rendered to HTML (right).

Figure 22: A Turkish-language presentation slide from Wikimedia Commons (left), and plain text output (right). Note that jina-ocr-v1 correctly recognizes the distinctly Turkish yumuşak g (ğ) and highly problematic “dotless i” (ı).

Greek and Cyrillic

In addition to Latin alphabet writing, jina-ocr-v1 supports Greek and Cyrillic writing:

Figure 23: Greek press release from the construction company GEK TERNA (ΓΕΚ ΤΕΡΝΑ) (left), and extracted text (right).

Figure 24: Ukrainian presentation slide (top), and Markdown output from jina-ocr-v1 rendered via HTML (bottom).

Asian and Middle Eastern languages

jina-ocr-v1 goes beyond Latin scripts. You can see its Japanese support in Figure 16, but it also handles other major Asian languages. 

Chinese:

Figure 25: Chinese. Public promotional materials for a new food traceability reporting system at Lǎoxiāng Jī Restaurants (老乡鸡) downloaded from Sina.cn (left), and rendered Markdown (including HTML table layout) from jina-ocr-v1 (right).

Korean:

Figure 26: Korean. Page 3 of Hyundai Group’s Q2 2026 earnings announcement in the original PDF (left), and rendered Markdown (right).

Thai:

Figure 27: Thai. A screenshot of the home page of the daily newspaper Thai Rath (ไทยรัฐ) on August 26, 2026 (top), and the text extracted text from it (bottom).

Hindi:

Figure 28: Hindi. A screenshotted headline from the BBC Hindi website (left), and jina-ocr-v1's extracted text (right).

Arabic:

Figure 29: Arabic. US government public information pamphlet about COVID-19 (left), and jina-ocr-v1’s extracted text (right).

Mixed-language documents

jina-ocr-v1 excels at materials with mixtures of languages:

Figure 30: US Department of Agriculture notice in English, Spanish, Vietnamese, Chinese, and Arabic (left), all correctly handled by jina-ocr-v1 (right).

Five ways to access the jina-ocr-v1 OCR API

jina-ocr-v1 belongs at or near the front of your data pipeline, preprocessing rendered text images into clean Unicode text and tractable structured formats. This adds value to every downstream part of your processes. Your data ingestion pipeline makes fewer errors, and your retrieval has greater accuracy. Plus, the data retrieved is more immediately usable, whether to human readers or agentic AI.

There are five ways to access and use jina-ocr-v1:

Elastic inference API and Elastic Inference Service

jina-ocr-v1 is available via the Elastic inference API and EIS as an inference endpoint.

Because jina-ocr-v1 returns streaming text, like a chat-style LLM, access to it is via the chat_completions interface. We’re integrating native support for PDFs into the Elastic service and will make it available in the near future. Until then, you’ll need to process PDF documents into images first.

Jina API

For users who want to try out jina-ocr-v1 or don’t want to access it via Elasticsearch’s service infrastructure, access via the Jina API is available using a standard HTTP service. This service uses prepaid tokens, with no fixed subscriptions, and comes with 10 million free tokens to try it out at no charge. 

For more information, visit the model’s page at jina.ai and the jina-ocr-v1 sandbox.

Local installation and on-prem licensing

Jina AI models are available for download and licensed commercial use via Jina On-Prem and from the model’s page at Hugging Face. Jina AI’s latest models are free for academic research and noncommercial use under a CC BY-NC 4.0 license. To commercially license local installations of , please contact Elastic Sales.

Jina AI Reader API

You can configure the  Jina AI Reader API service to use jina-ocr-v1 in conjunction with a variety of additional features, including automatic PDF- and HTML-to-image conversion. This is not a default setup. To configure Jina AI Reader API to use  jina-ocr-v1, add the following to the header parameters in your request:

X-Respond-With: jina-ocr-v1

To use this service, see the Reader API documentation page at jina.ai.

jina-ocr-v1 technical report and model card

For more information about , see the model’s technical report and page on Hugging Face.