how to build a claude project knowledge base that won't lie to you.

elisabeth hitz · july 14, 2026 · 6 min read

build a reliable claude project by uploading markdown files instead of raw pdfs, because the pdf's structure gets guessed at retrieval time on out-of-context chunks, which is exactly where wrong answers come from. the setup screen lists pdf, word, and text as accepted file types like they are interchangeable. for accuracy, they are not. the format you upload decides whether your knowledge base answers straight or quietly makes things up, and most people pick the format that hurts them.

a claude project is supposed to be the trustworthy version: your real documents, your facts, answers grounded in what you actually gave it. that promise only holds if the model can read what you uploaded cleanly. drop in a folder of pdfs and you have built a knowledge base on a shaky foundation. here is why, and how to build one that holds.

why do pdfs hurt a knowledge base more than a single chat?

in a normal chat, when you paste a pdf, the model at least sees the whole thing at once. in a project knowledge base, it does not work that way. your documents get split into chunks, and when you ask a question, the system retrieves the chunks that seem relevant and answers from those. the model is often working from a fragment, not the full document.

now combine that with what a pdf actually is: glyphs positioned on a page, with structure only implied by layout. the model has to guess the structure, and in a knowledge base it is doing that guessing on an isolated chunk, stripped of the surrounding context that would have helped it guess right. a table that spans a page boundary gets split across two chunks and neither half makes sense. a value loses the header that told you what it meant. this is the same failure behind claude getting tables wrong, except now it happens at retrieval time, on a fragment, where you have the least ability to catch it.

that is the trap. the pdf problem and the chunking problem multiply each other, and the result looks like a confident answer sourced from your own documents.

why markdown fixes the chunking problem

markdown gives the system clean seams to cut along. because headings are marked explicitly with ##, the chunks can split on those headings instead of at arbitrary page positions. each chunk arrives as a coherent section with its structure intact, its table whole, its meaning still attached. there is nothing to reverse-engineer because the structure was written in as plain text, exactly as covered in markdown vs pdf for claude.

so the retrieval step pulls back clean, self-contained sections instead of orphaned fragments. the model answers from material it can actually read. that single change, upload markdown not originals, removes most of the quiet inaccuracy people blame on the model.

the build, step by step

here is how to set up a project knowledge base that answers reliably. it takes a little more effort up front and saves you from wrong answers you would never have caught.

• convert each source to markdown. turn every pdf, word doc, and page into a .md file first, with a free tool like microsoft's markitdown or by asking claude to convert it. do not upload the original pdf.
• name files descriptively. use filenames the retrieval step can match on, like pricing-2026.md or refund-policy.md, not doc1.md. the name is a signal, so make it a useful one.
• upload the markdown, not the originals. this is the load-bearing step. clean chunk boundaries and surviving structure come from the format you upload, so upload the .md files and leave the pdfs out.
• put behavior in instructions, facts in files. the project instructions are for how claude should act and answer. the knowledge files are for what is true. keep those separate so rules do not get buried inside documents where they lose weight.
• verify with known questions. before you trust it, ask a handful of questions you already know the answers to and confirm each one. this is your accuracy check, and it is the difference between hoping and knowing.
• archive stale docs. when a document is out of date, remove it. a knowledge base with an old price sheet still in it will confidently serve the old price. fewer, current files beat a pile that includes contradictions.

why the instructions-versus-files split matters

one more thing that trips people up. they stuff behavior rules into the uploaded documents, "always respond formally," "never quote a discount," and then wonder why the model ignores them. rules buried inside a long file lose weight, the same reason more context is not better: things in the middle of a large body of text get less attention. put behavior in the project instructions where it stays prominent, and keep the files for facts. that division keeps both jobs clean and is part of why the whole base answers straight.

done right, a project knowledge base is the most trustworthy way to work with your own material. the reliability does not come from the model trying harder. it comes from you handing it clean, well-cut, current input, so there is nothing left to guess.

faq

do i have to re-upload everything as markdown?

to get the accuracy gain, yes, replace the pdfs with .md versions. converting is fast with a free tool or by asking claude, and you do it once per document. the payoff is a base that stops quietly making things up.

can i just upload word docs instead of converting?

word is better than pdf because it keeps real structure, but markdown gives the cleanest chunk boundaries and the leanest input. if converting is easy, markdown is the safer choice for a knowledge base.

how often should i check the knowledge base is still accurate?

run your known-question check whenever you add or change documents, and archive anything out of date at the same time. a quick verify after each update keeps stale facts from creeping in.