What Granite-Docling-258M does
Granite-Docling-258M is an open-weight vision-language model designed specifically for document conversion and understanding. Its main input is a document page image, optionally combined with a text instruction. Its main output is textual DocTags: structured markup that describes both the content on the page and its layout.
This focus distinguishes the model from a general chatbot or a broad image-question-answering system. Granite-Docling-258M is intended to turn PDFs, scans, and other page images into data that software can index, search, transform, or pass to downstream document workflows.
The model is provided by IBM Research and is distributed through the IBM Granite Hugging Face organization under the identifier ibm-granite/granite-docling-258M. The supplied research identifies it as a current open-weight model released on September 17, 2025, under the Apache 2.0 license.
DocTags and document structure
Traditional OCR often extracts words while losing important relationships between page elements. Granite-Docling-258M is designed to preserve more of that structure. Its DocTags representation can describe reading order, headings, tables, charts, mathematical formulas, code, captions, footnotes, and other document elements.
DocTags are textual rather than visual output, but they are intended to be consumed by document-processing software. Through the Docling ecosystem, the result can be loaded into a DoclingDocument object or exported to formats such as Markdown, HTML, and JSON. This makes the model useful when the destination is a searchable corpus, structured dataset, retrieval-augmented generation system, or enterprise document pipeline.
For example, a page containing a heading, two paragraphs, a table, and a formula can be converted into an output that records those elements separately instead of presenting them as one undifferentiated text block. The exact quality of the result depends on the source image, document complexity, runtime, and inference configuration.
Architecture and technical profile
Granite-Docling-258M contains approximately 258 million parameters. It builds on the IDEFICS3 architecture and combines a SigLIP2 Base Patch16 512 vision encoder with a pixel-shuffle projector and a Granite 165M language model. IBM reports that the model was trained with its nanoVLM framework using publicly available data and internally constructed synthetic data.
The training data included examples for document pages, code, mathematical formulas, and charts. IBM also incorporated DocTags into supervised fine-tuning data to improve the model’s familiarity with the target format and help it converge on structured document outputs.
The model’s documented context window is 8,192 tokens. IBM’s documentation and examples also describe configurations with up to 8,192 newly generated tokens. These are token limits rather than guarantees about how much usable text a particular page will produce; image resolution, prompt content, and runtime configuration still affect practical behavior.
Supported inputs and outputs
| Category | Granite-Docling-258M |
|---|---|
| Text input | Supported, generally as an instruction or prompt accompanying document processing |
| Image input | Supported; document page images are the primary visual input |
| Audio input | Not supported |
| Video input | Not supported |
| Text output | Supported; the primary output is textual DocTags |
| Native image, audio, or video output | Not supported |
| Structured document output | DocTags can be converted into Markdown, HTML, JSON, and DoclingDocument representations |
Structured document export should not be confused with a general-purpose hosted JSON mode. The supplied research does not verify a separate provider-managed JSON-mode feature. Instead, structured formats are produced through the model’s DocTags workflow and the surrounding Docling tooling.
Core document capabilities
- OCR and text extraction: Converts text in document images into machine-readable output.
- Layout preservation: Represents the organization and reading order of page content rather than extracting only a flat text stream.
- Tables: Recognizes tables and can represent them in structured downstream formats.
- Formulas: Handles inline and block mathematical formulas.
- Code: Recognizes code displayed in documents and converts it to text.
- Charts: Can convert chart content into structured tables.
- Document elements: Identifies elements such as headings, captions, footnotes, and other parts of a page.
- Limited structure questions: Supports some document-element identification and document-structure question answering.
IBM also describes experimental support for Japanese, Arabic, and Chinese documents. The supplied research cautions that these multilingual workflows have not been validated to the same level as the model’s primary English and Latin-script use cases.
How to deploy the model
The recommended integration path is the open-source Docling library, which can download and use Granite-Docling-258M as part of a vision-language document-conversion pipeline. Direct inference is also available through Transformers-compatible classes, vLLM, MLX-based tooling, and compatible local runtimes.
Because the model is open-weight rather than primarily offered as an IBM per-token service, deployment responsibility rests with the user or the selected inference provider. Hardware, image resolution, batching, quantization, and runtime implementation can materially affect memory use, latency, and throughput. The model’s relatively small parameter count makes local inference more practical than deployment of much larger vision-language systems, but the supplied research does not establish a universal hardware requirement or guaranteed latency.
Speed, cost, and capability trade-offs
Granite-Docling-258M’s main trade-off is specialization. It is small and designed for a narrow but valuable task: converting documents into structured representations. That makes it a potentially efficient choice for local batch processing, private document workflows, and applications where sending pages to a hosted API is undesirable.
It should not automatically be compared with large general-purpose multimodal models on broad reasoning or open-ended visual understanding. Larger models may be more appropriate when an application needs extensive conversational reasoning, complex visual interpretation outside documents, or general knowledge. Granite-Docling-258M instead prioritizes document structure, a compact footprint, and integration with Docling.
The supplied editorial assessment rates its speed at 9 out of 10 and cost efficiency at 9 out of 10 for its intended use case. These are comparative editorial estimates, not IBM-published benchmark results. The same assessment rates reasoning at 4 out of 10 and coding at 3 out of 10, reflecting the model’s document-conversion specialization rather than a lack of ability to recognize formulas or code embedded in documents.
Pricing and API availability
IBM does not list an official per-token hosted API input or output price for this checkpoint in the supplied research. Granite-Docling-258M is an open-weight model intended for local deployment or use through compatible third-party inference infrastructure.
As a result, there is no verified IBM monthly subscription or token price to quote. The effective cost depends on the hardware, cloud instance, inference service, processing volume, and serving configuration chosen by the user. This can be advantageous for predictable batch workloads, but it also means that the user must manage deployment or select a separate provider.
Limitations and unsupported features
Granite-Docling-258M is not a general-purpose chat model. IBM recommends broader Granite Vision models for general image-text tasks. The model may produce inaccurate, biased, or incomplete results, particularly when pages are visually difficult, contain unusual layouts, or fall outside its best-supported document patterns.
Its experimental multilingual support should be evaluated carefully before production use. Japanese, Arabic, and Chinese processing is documented as experimental, while the model is optimized primarily for English and Latin-script workflows.
The model does not provide native image, audio, or video generation. The supplied research also does not verify tool calling, function calling, streaming, batch APIs, web search, or audio and video processing. It should therefore be selected for document conversion, not for agentic workflows that require built-in external tools.
When to choose Granite-Docling-258M
Choose Granite-Docling-258M when the central requirement is converting document pages into structured data while retaining layout information. It is especially suitable for:
- OCR pipelines where reading order and page structure matter;
- table, chart, and formula extraction;
- document indexing and search preparation;
- retrieval-augmented generation preprocessing;
- conversion of documents into Markdown, HTML, JSON, or DoclingDocument objects;
- local or private document processing;
- batch workflows that benefit from a compact open-weight model.
Choose another type of model when the primary task is open-ended conversation, broad image understanding, audio or video analysis, image generation, or complex tool-using automation. A larger general-purpose multimodal model may offer stronger reasoning outside the document domain, while a hosted OCR service may be simpler if managed infrastructure and predictable API operations are more important than local control.
Overall assessment
Granite-Docling-258M is best understood as a focused document-conversion component rather than a small general-purpose assistant. Its value comes from combining page-image understanding with DocTags output and Docling-compatible structured exports. For teams that need layout-aware OCR and can operate local or compatible inference infrastructure, its compact size and Apache 2.0 licensing are important practical advantages.
Its limitations are equally important: there is no verified IBM hosted token price, no broad chat positioning, no native non-text output, and only experimental support for some languages. The model is a strong candidate when structured document conversion is the goal, but a poor fit when document processing is only one part of a wider multimodal or agentic application.

