Uploading Knowledge Files to a Project

Knowledge files turn a Project from a set of instructions into a workspace with an actual reference library behind it.

Summary

Custom instructions tell Claude how to behave. Knowledge files give Claude something concrete to check its answers against.

Once a file is uploaded to a Project, every conversation started inside that Project can draw on it, without anyone needing to attach it manually each time.

This matters most for work that depends on specific facts, terminology, or source material that a general-purpose answer would get wrong or leave generic.

This page covers what makes a good knowledge file, how to upload one, and the mistakes that quietly make a Project's files less useful than they should be.

The goal is a small set of well-chosen files that a conversation can actually use, not a large pile of documents that dilute each other.

Recipe

Quick-reference steps - the fastest path from an empty Project to one with working reference material.

Open the Project and find the knowledge or "Add content" section in its settings.
Choose a file that is directly relevant to the Project's stated purpose - not just something that seems generally useful.
Upload it, and give it a clear name if the interface allows renaming, so it is easy to recognize later.
Start a new conversation and ask a question that should draw on the file, to confirm Claude is actually using it.
Repeat with additional files only as real gaps show up in test conversations, rather than uploading everything at once.

When to reach for this:

The Project's task depends on specific facts, numbers, or terminology that a general answer would get wrong.
You find yourself pasting the same reference material into multiple conversations.
A style guide, glossary, or spec exists and should be applied consistently across a whole Project's output.
New team members using the Project need the same source material without hunting it down separately.

Working Example

A product marketing Project might build its knowledge files up like this, in order, as real gaps appear:

First upload: a one-page product overview covering what the product does, who it's for, and its key differentiators, since almost every conversation in the Project needs that baseline.

Second upload, added after a test conversation used the wrong terminology: a short glossary defining the product's specific feature names and any terms the team is picky about (for example, always "workspace," never "account" for a specific concept).

Third upload, added once the Project started producing copy for a specific launch: a one-page brief for that launch, covering audience, key message, and any claims that are off-limits for legal reasons.

What the Project deliberately does not include: the full 40-page brand guidelines document, because most of it is irrelevant to day-to-day copywriting and would compete with the more targeted files for the model's attention.

What this demonstrates:

Files were added incrementally, based on real gaps, not uploaded speculatively all at once.
Each file has a narrow, specific purpose rather than trying to be a comprehensive reference.
A large, only-partially-relevant document was deliberately left out, even though it technically "could" have been useful.
The set of files stays small enough that a person could still explain what each one is for.

Deep Dive

How It Works

Uploaded knowledge files are attached to the Project itself, not to any single conversation, so every new chat inside the Project can draw on all of them.
Claude uses the files as reference material when relevant to what you're asking, rather than repeating their contents wholesale in every response.
Files remain available across sessions - you do not need to re-upload them for each new conversation.
Removing a file from the Project stops it from being used in new conversations going forward.

Choosing What to Upload

Good candidate	Why it works	Weak candidate	Why it struggles
A one-page product overview	Concise, directly relevant to most conversations	A 60-page internal wiki export	Too broad, buries the useful parts
A glossary of exact terminology	Answers a specific, recurring need	A general dictionary or style guide from another team	Not scoped to this Project's actual task
A recent, accurate data reference	Keeps answers grounded in current facts	An outdated spreadsheet nobody has corrected	Produces confidently wrong answers

Keeping a File Set Healthy

A knowledge file set tends to degrade the same way an overstuffed folder does: useful files get buried under files that were "might as well" uploads.

A practical habit is to ask, for each file already in the Project, whether a recent conversation actually needed it. Files that never come up in real use are candidates for removal.

Outdated files are a sharper risk than merely unused ones, since Claude has no way to know a file is stale - it will treat old numbers or old terminology as current unless you remove or replace the file.

Gotchas

Uploading a large, only-partially-relevant document "just in case." It buries the narrow, useful sections inside irrelevant ones. Fix: extract or write a shorter, purpose-built version instead of uploading the whole source document.
Leaving outdated files in place after the underlying facts change. Claude has no way to know a file is stale. Fix: replace or remove outdated files as soon as you know they're wrong.
Uploading files that overlap or contradict each other. Two files with different numbers for the same thing produce inconsistent answers. Fix: consolidate into one current source before uploading.
Assuming a file was used just because it was uploaded. Relevance still matters - an unrelated question won't pull from a file that has nothing to do with it. Fix: test with a question that should clearly need the file, and confirm the answer reflects it.
Treating knowledge files as a place to store unrelated documents for safekeeping. A Project's files are meant to be operationally useful, not an archive. Fix: keep a separate storage location for anything that isn't actively feeding the Project's conversations.

Alternatives

Alternative	Use When	Don't Use When
Pasting reference material directly into a message	The material is short and only needed for one conversation.	You'd otherwise be re-pasting the same content across many chats.
One large combined reference document	The Project's scope is genuinely broad and one document stays coherent.	The document mixes unrelated topics - split it into targeted files instead.
No files, custom instructions only	The Project's task depends only on tone and rules, not specific facts.	Answers need to reflect specific, checkable source material.

FAQs

What kinds of files can I upload to a Project?

Common formats include documents, spreadsheets, and plain text files with reference material relevant to the Project's purpose. Check your current Claude.ai interface for the exact supported formats, since this can expand over time.

Is there a limit to how many files or how much content I can upload?

Yes, Projects have a knowledge capacity that varies by plan and can change over time. Check the current limits shown in your Project's settings rather than assuming a fixed number.

Do I need to reference the file by name when I ask a question?

No. Claude draws on relevant uploaded files automatically based on what you're asking, without needing you to name the specific file.

What happens if I upload two files with conflicting information?

Claude has no reliable way to know which one is correct, so answers can become inconsistent. Consolidate conflicting files into one current, accurate source instead of uploading both.

Do knowledge files apply to every conversation in the Project, or just the current one?

Every conversation started inside the Project can draw on all of that Project's uploaded files, not just the conversation open when you uploaded them.

Should I upload my entire company wiki to be safe?

No. A large, mostly irrelevant upload tends to bury the genuinely useful material and can dilute answer quality. A small set of purpose-built files works better than one comprehensive dump.

How do I know if a file I uploaded is actually being used?

Ask a test question in a new conversation that should clearly require that file's content, and check whether the answer reflects it. If it doesn't, the file may be too broad, poorly matched to the question, or genuinely not relevant.

Can I remove a file after uploading it?

Yes. Removing a file from the Project's knowledge section stops it from being used in new conversations going forward.

What's the difference between a knowledge file and custom instructions?

Custom instructions describe how Claude should behave - tone, format, rules. Knowledge files supply the actual reference material and facts Claude can draw on. Most effective Projects use both.

Should I update a file in place, or upload a new version alongside the old one?

Replace the outdated file rather than leaving both in the Project. Keeping both risks Claude drawing on the stale version or producing inconsistent answers from conflicting sources.

Do uploaded files count against the same limits as the conversation itself?

Knowledge files and conversation content are managed separately in how they contribute to a Project's overall capacity, but both ultimately draw on the same underlying context budget. Very large file sets can leave less room for other context, which is another reason to keep the file set focused.

Can everyone on a team see the files uploaded to a shared Project?

If the Project is shared with a team, uploaded files are generally visible to everyone with access to that Project. Check your workspace's specific sharing and permissions settings, since this depends on your plan and admin configuration.

Setting Up a Project with Custom Instructions - the other half of a Project's setup.
What Makes a Good Project: Scope and Shared Context - why well-chosen files matter more than a large file count.
Project Setup Checklist: Instructions, Files, and Scope - a checklist covering this whole setup flow.
Projects & Artifacts Basics - a broader first walkthrough of creating a Project.

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.