prebuilt-read vs prebuilt-layout: Which Azure Document Intelligence Model Should You Call?

The short answer: use prebuilt-read when you need text, handwriting or a searchable PDF, and prebuilt-layout when you need tables, selection marks or markdown. Read costs $1.50 per 1,000 pages and Layout costs $10.00, so Layout is 6.7 times more expensive on the same documents. Read cannot return tables at any price, because its documented response has no tables collection at all. Layout, despite costing far more, cannot produce a searchable PDF.

That last sentence is the part almost nobody knows, and it is the reason this comparison is worth more than a price column. Every other upgrade decision in cloud document processing follows the pattern you expect: pay more, get a superset. This one does not. Moving up to Layout gains you structure and loses you a capability that ships free on the cheaper model.

Everything below was read off Microsoft Learn on 16 August 2026, from the Document Intelligence overview and the prebuilt-read model page (both carrying an ms.date of 15 August 2026), with rates pulled from the public Azure Retail Prices API for the eastus region.

What prebuilt-read actually returns

Read is the OCR engine underneath everything else in Document Intelligence. Microsoft describes it as the model that "extracts print and handwritten text from PDF documents and scanned images" and notes that it "is the underlying OCR engine for other Document Intelligence prebuilt models like Layout, General Document, Invoice, Receipt, Identity (ID) document, Health insurance card, W2 in addition to custom models." When you call Invoice, you are paying for Read plus a field model on top.

The documented response contains five things worth naming:

• pages, each with an orientation angle, width, height and unit
• paragraphs, as a top-level collection under analyzeResults, each with content and a bounding polygon
• lines and words, with bounding polygons and a per-word confidence
• styles, which carries isHandwritten and a confidence score per span
• languages, when language detection is on

Notice what is not on that list. There is no tables collection. This matters more than it sounds, because it means the limitation is structural rather than a matter of tuning. You cannot prompt your way to a table, raise a threshold, or pass a parameter that makes Read return rows and columns. The field does not exist in the response schema. If your document has a table you need, Read is the wrong call regardless of budget.

Read also handles input formats the other models do not. It accepts Word, Excel, PowerPoint and HTML alongside PDF and images, computing page units at up to 3,000 characters per page for text formats, one page unit per worksheet for Excel and one per slide for PowerPoint.

What prebuilt-layout adds

Layout is Read plus structure. It returns everything above, then adds the tables array, with rowCount, columnCount and a flat cells array where each cell carries rowIndex, columnIndex and span information. Header cells are marked with cell.kind set to "columnHeader", which is worth knowing because assuming row one is the header will be right often enough to hide the bug and wrong often enough to matter.

Layout also adds selection marks (checkboxes, rendered as ☒ and ☐), section and hierarchy detection, and the single feature most teams actually arrive for: outputContentFormat=markdown. Markdown output is a Layout feature and only a Layout feature. Read does not have it.

One detail catches people building retrieval pipelines. Azure does not emit standard pipe tables inside its markdown. It writes HTML tables, with rowspan, colspan and caption elements, on the grounds that pipe syntax cannot express a merged cell. Page furniture also hides in HTML comments such as <!-- PageHeader="..." -->, and pages are separated by <!-- PageBreak -->. If you strip HTML from the markdown before indexing it, you will delete every table you paid extra for.

The capability only the cheap model has

Here is the finding. Microsoft's Read documentation states plainly: "Currently, only the Read OCR model prebuilt-read supports the searchable PDF capability. When using this feature, specify the modelId as prebuilt-read. Other model types return an error."

A searchable PDF is a scanned document with a text layer welded on top of the image, so the pages look identical but the words can be selected, copied and found. It is what most organizations actually want when they say they want to digitize an archive. On Azure you get it by adding output=pdf to the Analyze request, polling the operation, then issuing a GET to the /analyzeResults/{resultId}/pdf endpoint, which returns application/pdf rather than base64 inside JSON.

And it is free. The docs are explicit that searchable PDF "is included with the 2024-11-30 GA prebuilt-read model with no added cost for generating a searchable PDF output."

So the model that costs $1.50 per 1,000 pages can produce a searchable PDF at no extra charge, and the model that costs $10.00 per 1,000 pages returns an error if you ask. If you assumed the expensive model was a superset and standardized your whole pipeline on Layout, you have quietly paid 6.7 times more for less. Once those pages carry a real text layer they finally become findable, which is usually the point of the exercise and the reason the searchable-PDF step tends to sit right before whatever tool your team uses to search across internal documents.

The two models side by side

Both models share the same input ceilings: 500 MB per file on the paid S0 tier against 4 MB on the free F0 tier, up to 2,000 pages for PDF and TIFF, and image dimensions between 50 by 50 and 10,000 by 10,000 pixels. On a free-tier subscription only the first two pages of a document are processed, which is the single most common cause of a proof of concept that appears to lose most of its content.

Is prebuilt-read or prebuilt-layout cheaper?

Read is cheaper by 6.7 times, at $1.50 per 1,000 pages against $10.00. Read also has a volume tier that Layout does not: it falls to $0.60 per 1,000 pages above one million pages a month. Read the unit carefully on that tier, because the Retail Prices API expresses it in thousands, so the threshold is 1,000,000 pages and not 1,000. Both rates carry an effective date of 1 March 2022 on the meter named "S0 Read Pages".

On a million pages a year, the difference between the two models is roughly $1,500 against $10,000. That gap is worth a few hours of thinking about which pages genuinely contain tables, because in most real document sets it is a minority. Splitting the workload, sending everything through Read and routing only the pages that need structure to Layout, is a legitimate and commonly overlooked optimization.

Which should you use?

Use prebuilt-read if you are digitizing an archive, extracting text for search or retrieval, handling handwriting, working with Office or HTML files, or producing searchable PDFs. Use prebuilt-layout if you need table structure, checkboxes, document hierarchy, or markdown for a generative pipeline. If you need typed fields from a known document type such as an invoice or a W2, skip both and call the matching prebuilt model, which is $10.00 per 1,000 pages and returns the fields already labeled rather than making you locate them in a grid.

The wider point is that Azure prices per model ID, not per service, and the string in your request URL is the meter. The same is true on the other clouds, where AWS bills per operation and per FeatureType and Google bills per processor type. We keep a cross-vendor map of every one of those identifiers, what it returns and what it costs, on OCR API operations and model IDs. If you are working out a budget rather than an integration, Azure Document Intelligence pricing covers the full rate card, and OCR pricing per 1,000 pages normalizes every vendor to a single unit.

One last thing worth saying out loud: neither model gives you a finished system. You still need somewhere to queue failures, a rule for when a confidence score is too low to trust, a screen where a person corrects a value, and an export into whatever actually needed the data. That work is usually larger than the API call, which is the honest argument for using a product rather than assembling one. If tables are what you are after, converting a PDF to CSV covers what each vendor hands back and what it costs to ask.