PDF to Markdown APIMarkdown a model can read, not a wall of extracted text
Inteleto converts PDFs to Markdown that keeps the structure a model needs: headings stay headings, tables become Markdown pipe tables with merged cells flattened into a real grid, and every block keeps the page it came from. Scanned pages are recognised in the same pass, so a mixed archive comes out as one consistent document rather than half text and half nothing.
Digital pages are read from the text they already carry. Scanned pages are recognised instead. One clean document comes out either way.
Private beta · no card · we reply by hand
What survives the conversion
Extracting the words from a PDF is the easy half. The half that decides whether the output is usable is how much of the document's structure survives — because structure is where most of the meaning in a business document actually lives.
Heading structure
Headings come back as headings, at the right level. Everything under one stays scoped to it, which is what makes a chunk of the document intelligible on its own.
Real pipe tables
Tables are rewritten as Markdown pipe tables. Colspans and rowspans are flattened into a proper grid rather than dropped, so no column silently shifts.
Page numbers
The Markdown is assembled from positioned blocks, and those blocks come back with it. Render the Markdown and you can still cite page 41 of the original.
Reading order
Multi-column pages, sidebars and footnotes are ordered the way a person reads them, not the order the glyphs happen to sit in the file.
The table problem, specifically
Raw recognition output wraps every table in a great deal of presentation markup — the same styling repeated for every cell, hundreds of times over in a single table. Passed straight to a model, that is thousands of tokens of noise carrying no information at all, in the part of the document most likely to hold the number someone is looking for.
All of it is stripped, and the table is rewritten as Markdown — expanding merged cells into every position they spanned, because a pipe table cannot express a merge and dropping one shifts every column after it.
Small print is where parsers quietly break
Most tools render a scanned page at whatever default resolution they inherit, and that default blurs small print. Controlling how the page is rendered before it is ever read removed a measurable class of misreads — the kind where claims comes back as ciaims and nothing downstream ever matches it again. Small, unglamorous, and worth more than most model swaps.
Frequently asked questions
- Why does Markdown quality matter for an LLM?
- Because structure is most of the meaning in a document. A table flattened into a paragraph loses which number belongs to which column, and a heading that arrives as ordinary text loses the scope of everything under it. Raw OCR output also carries a great deal of presentation markup around tables — pure token cost with no information in it — and that is stripped before the Markdown is written.
- What happens to tables with merged cells?
- Colspans and rowspans are flattened into a proper grid, so the value that visually spanned three columns appears in all three. A Markdown pipe table cannot express a merged cell, and dropping the span instead of expanding it silently shifts every column after it.
- Do I lose the page numbers when I convert to Markdown?
- No. The Markdown is assembled from positioned blocks, and those blocks are returned alongside it with their page number and position. You can render the Markdown and still point a citation at page 41 of the original.
- Does it work on scanned and image-only PDFs?
- Yes, and on files that mix the two. The route is decided per page: a page with a usable text layer is read from it, a scanned page is recognised instead. Pages are rendered for recognition at a resolution we control rather than a default, which is what keeps small print from being misread.