PDF to Markdown for LLMs: prepare reliable input

A model cannot rescue information that disappeared during conversion. PDF to Markdown for LLM use starts with the source. Check the text before making the prompt bigger. Keep headings, table labels and source references; then split the content into useful sections. Prepare text you can read and trace back to the source. Markdown cannot stop a model making things up. Nor does it build a full search system on its own. The worked example shows how a small unit mistake can survive an otherwise polished extraction.

The failure happens before the question

Picture an illustrative quarterly report with a table headed “Revenue, £000”. A conversion keeps the numbers but drops the unit. A model then gives a fluent answer using pounds instead of thousands of pounds. The maths may fit the text you supplied. Yet the answer could be a thousand times too small. Asking the model to “be accurate” cannot restore a missing label reliably.

That is why input review needs its own acceptance rule. Compare the extracted material with the source before testing answers. Keep the report name and section title. Add the period, units and any notes that limit the figures. If the source is unclear, say so in a note. Do not hide the doubt. Do not turn an uncertain source into a confident-looking table merely because Markdown makes the table easy to render.

The CommonMark specification describes the aim as “writing structured documents”. Structure helps you see how the parts fit. It gives the tool those clues too. It is not a certificate of truth. A neat heading can make a wrong paragraph seem right. Check the meaning as well as the syntax.

What should PDF to Markdown for LLM input preserve?

Keep enough context to make each point clear on its own. A heading tells you what a section concerns. A date tells you when it applies. A unit tells you what the figures mean. A source reference gives you somewhere to check the answer. You can remove repeated decoration. Check first that it adds no facts. Keep each claim with the notes that limit it.

For a policy, preserve exceptions and definitions close to the relevant rule. For research, keep doubts, sample details and figure captions. For a financial report, retain periods, currencies and whether values are totals or rates. One cleaning pass cannot make all those choices safely. The person checking the text needs to know what it will be used for.

Use the PDF-to-Markdown conversion guide for the initial extraction. In Lass0, the whole-document path is preferable to a chain of overlapping screenshots when you need the full file. Check the pages you plan to ask about. A good first page does not prove the rest are right.

Design sections around meaning

A section should contain enough context to answer a focused question. A fixed-size split can cut a table from its caption. It can also cut a rule from its exception. Start with the document hierarchy. Keep a heading with its text where you can. Split a long section at a clear paragraph or smaller heading. Add source information to every exported part.

Do not mistake word count for token count. Tokens depend on the model and the text. Language, code and symbols all affect the count. Check the service's current limits and token counter. Use them to decide how much text to send. Leave room for the question and response as well as the document. A large context window is not enough. Check that the part you need was actually included.

If a table spans a split, repeat its header and unit in the new part. Mark it as a continuation, not a separate dataset. For a long list of definitions, consider keeping the definitions together with the sections that depend on them. Make the source easier to use. Do not add facts or force it into an outline that changes its meaning.

Table: proposed context packets for an illustrative report. Sizes are not model limits or measured performance figures.

A small provenance record beats a clever filename

Record the source filename or a stable ID. Add its version or date. Note the section or page as well. Add a conversion date when it helps distinguish repeat exports. Keep this record apart from the source claims. The reader should know which words are yours and which came from the document.

For a public report, include its official URL. For an internal file, use an approved reference. Avoid paths that reveal a username or private project name. If two documents have the same title, include a version or period. Without that, the source may be hard to find. A reader could also confuse this month's policy with last month's draft.

A simple note might read: “Source: annual report, table 4, pages 18–19; values in thousands; extracted 16 October 2026.” This is an illustrative record, not a citation to a real report. The useful property is traceability. A reader should be able to find the source of a value. They should not have to trust the model's memory of the chat.

How do I check tables before model use?

Compare row labels first, then units and values. Check missing values explicitly: a dash, zero and blank cell do not necessarily mean the same thing. Preserve the source convention or explain it in a labelled note. Check the total if the source gives enough detail. A matching sum helps, but it cannot prove each value is in the right row.

The GFM table specification defines how pipe tables are represented. It does not recover merged headers or infer units for you. Flatten a multi-level header only after checking the resulting label. “North / 2025 / net” may be more useful than a column called “Value”, because it carries the original distinctions into the text representation.

For more complex cases, follow the PDF table review. Keep a companion source image or PDF when the visual structure carries information that the Markdown cannot express cleanly. If you simplify the data, state the limit clearly. Do not make it look complete when it is not.

Does Markdown make model answers reliable?

It can make input easier to inspect and organise. It cannot guarantee a right answer. A model can still ignore the source or make a claim the text does not support. Test the system with questions you can check. Keep that test separate from checking the text. Ask a question the text cannot answer. Does the system say that the answer is missing? A useful workflow must handle absence as well as retrieval.

Treat instructions inside a document as source content, not permission to change the application's behaviour. A report can contain quoted prompts, malicious text or irrelevant commands. Keep the user's task separate from the text being read. Make that boundary clear in the system that uses it. The NCSC's secure AI development guidance is a primary starting point for system-level risk review.

Before submitting sensitive material, review the redaction workflow and the recipient service's current data settings. A local export stays on the device. A later upload sends it away. Start with one non-sensitive document, verify its structure and provenance, then test a handful of answerable and unanswerable questions. Expand the workflow only when both the extraction and answer checks are sound.

Questions, answered

Is Markdown always better than PDF for an LLM?

No. It makes text structure inspectable, but visual documents may need image-aware processing or the original PDF. Evaluate the actual task and model.

How large should each document chunk be?

Use meaningful section boundaries and the consuming model’s current limits. Keep tables, units and qualifications together; do not rely on a universal word-to-token ratio.

Does local PDF conversion keep my later prompt private?

Only the conversion is local. Once you paste or upload the output, the destination’s processing and retention rules apply.