claude keeps getting my table wrong. here's the actual fix.

elisabeth hitz · july 14, 2026 · 5 min read

claude misreads your table because it is trapped in a pdf, and a pdf has no real cells, so the fix is to convert the file to markdown before you ask anything. you have probably rewritten the prompt five times. it is not the prompt. the numbers are landing in the wrong cells because the table was never a table to the model in the first place, it was a scatter of digits positioned on a page. give it a real table and the problem disappears.

this is one of the most common ways ai quietly burns people, because the output looks right. a clean table comes back, formatted nicely, totally confident. you only catch it if you happen to know one of the values by heart. let me show you why it happens and how to end it for good.

why does claude scramble the numbers?

open a pdf and you see a table with rows and columns. the model does not see that. a pdf does not store cells, borders, or which number belongs to which row. it stores glyphs at coordinates: the character "4" at this x-y position, the character "2" a little to the right. the grid you see is an illusion created by spacing. the structure exists in your eyes, not in the file.

so when claude reads the pdf, it has to reconstruct the table from the positions. it looks at which digits sit near each other and guesses the rows and columns. on a simple, well-spaced table it usually guesses right. but the moment the layout gets tight, or a cell wraps to two lines, or two columns sit close together, the reconstruction slips. a value from the "q2" column drifts into "q1". a figure from the row above attaches to the row below. the model is not being careless. it is solving a puzzle that has no correct answer built into the file.

the same root cause is why you should stop feeding claude pdfs in general. tables are just where it hurts most, because a small position error becomes a wrong number instead of a slightly awkward sentence.

the worst case: confident, wrong numbers

there is a failure mode nastier than a scrambled cell. sometimes the reconstruction is ambiguous enough that the model fills a gap with a value that fits the pattern but was never in your document. you get a complete, plausible table with a number that does not exist anywhere in the source. this is the same mechanism behind why ai makes things up, when the input is unclear, the model reaches for something that looks right. with a messy table, "looks right" and "is right" are not the same thing, and you cannot tell them apart by looking at the output.

that is the real risk. not that you will catch an obvious mistake, but that you will not.

the 90-second fix

convert the document to markdown first, then ask your question against the markdown. a markdown table has real, explicit rows and columns written in plain text with pipes, so there is nothing to reconstruct and nothing to guess. here is the whole routine.

• convert before you ask. if you have the original google doc, sheet, or word file, export or copy the table from there. otherwise run the pdf through microsoft's free markitdown or a free web converter, or paste the pdf into claude with this one line first: "convert this document to clean markdown, preserve the table exactly, do not fill in or infer any values." then do your real work against that output.
• spot-check two or three known values. before you trust the result, pick a couple of cells you already know and confirm they match. thirty seconds. if they are right, the structure survived. if they are off, you caught it early instead of shipping it.
• ocr first if it is scanned. a scanned or photographed table is just pixels with no text underneath, so no converter can read it directly. run optical character recognition to pull the text out first, then convert to markdown, then verify. scanned tables are the highest-risk case, so the spot-check matters most here.

that is it. the reason people fight the prompt for an hour is that they assume the model is misunderstanding the request. it understands the request fine. it is working from a file that does not contain the table you think you gave it. fix the file and the prompt you already had works.

if you want to know whether a given answer can be trusted at all, the same habit generalizes, and it is worth reading how to pick the right format for ai work before your next document lands wrong.

faq

can't i just tell claude to be careful with the table?

no amount of careful helps, because the information is not in the file. you cannot prompt the model into reading cells that were never stored. you have to give it a format that actually has cells.

does converting to markdown lose my formatting?

it drops the visual styling, fonts and colors and borders, but it keeps the thing that matters for a table: which value is in which row and column. for feeding ai that is exactly the part you want to preserve.

how do i know if the conversion worked?

spot-check two or three values you already know against the markdown output. if they line up, the structure held. it is the fastest reliable check and it takes under a minute.