How to Upload Files to a Custom GPT

Uploading knowledge files to a custom GPT lets the assistant search a specific body of text when answering questions. Without files, the assistant draws on its base training. With files, it can search your uploaded content and answer from it, which is useful when your questions involve internal terminology, product details, or domain-specific reference material the base model does not have.

Keeping the source references and the instructions needed to maintain those files outside the GPT is equally important. fenbs stores your project context and prompt instructions so you can update the assistant later without losing track of what was uploaded and why.

File types the builder accepts

The custom GPT builder accepts several common file formats. Plain text files (.txt) and clean PDFs work most reliably. Word documents (.docx), PowerPoint files (.pptx), and spreadsheets (.xlsx, .csv) are also supported. The assistant reads the text content of these files; it does not process images, charts, or formatting in the same way a reader would.

OpenAI updates accepted file types and size limits as the platform evolves. Before uploading, check OpenAI's help center↗ (opens in a new tab) for the current list of supported formats and the maximum file size per file and per GPT.

ZIP files are not a supported knowledge format. If you need to upload multiple files, add them individually. The builder has a limit on how many files you can attach to one GPT; that limit is set by OpenAI and changes with plan updates.

What works well

Files that work well as knowledge sources share a few properties: they are text-heavy, well-structured, and current. Specific types that upload reliably and produce good results:

• Style guides and writing standards, especially if they contain specific rules and examples.
• Product or service descriptions in plain language without heavy formatting.
• Glossaries and terminology lists, particularly for domains with specialized vocabulary.
• Approved answer sets for frequently asked questions.
• Policies and procedures written in clear, numbered steps.

What to avoid

Some file types and contents produce unreliable results:

• Scanned PDFs: these contain images of text, not extractable text. The assistant cannot reliably read them.
• Heavily formatted documents: tables with merged cells, complex multi-column layouts, and embedded charts are hard to extract cleanly. Convert them to plain text before uploading.
• Outdated content: a document that describes a procedure you changed will produce outdated answers. Review files before upload.
• Files that contradict the instructions: if a document says one thing and the instructions say another, the assistant must choose. Resolve conflicts before uploading.
• Very large files: large files are processed more slowly and may be truncated. Split large documents into focused sections.

Updating files when content changes

The builder does not version your knowledge files. When you upload a new version, the old one is replaced. There is no history of what was uploaded before. This means two things: keep your own copy of every file outside the builder, and record when you changed a file and why.

A practical update process: when a document changes in the real world (a policy update, a product revision), flag the corresponding knowledge file for review. Review it, update the text, and re-upload. Test with the questions that are most likely to use that file before saving the updated GPT.

Maintaining the source outside the GPT

The source of truth for your knowledge files should not be the GPT itself. If you lose access to a GPT, if OpenAI changes the platform, or if you want to use the same reference material in a different assistant, you need the source files stored elsewhere. Keep the original documents in a folder, a shared drive, or attached to the project record in a tool like fenbs.

For knowledge that changes often or comes from multiple sources, consider keeping it as structured project context in fenbs instead of uploading static files. An assistant connected to fenbs reads the current project context at the start of every session, so it does not need a re-upload when something changes.

A combined approach works well: stable reference material (a style guide, a glossary, an approved template set) goes in the knowledge files because it changes rarely and benefits from search. Actively changing project information (current status, recent decisions, open questions) lives in fenbs where every connected assistant reads the latest version automatically.

How to do this with fenbs

1. Create a free account and add a project for the area this GPT covers.
2. Before uploading each file, add a context note in fenbs: the file name, what it covers, and when it was last reviewed.
3. Store the source file outside the GPT (in the fenbs project, a shared drive, or a version-controlled folder).
4. When a source document changes, update the context note and re-upload the file to the GPT.
5. Add a Lessons learned entry if an outdated file produced a wrong answer, so the next review catches it earlier.

For the full setup process, see the custom GPT builder guide or how to build a custom GPT. For guidance on knowledge files alongside other configuration, see Claude Projects vs. custom GPTs.