[Question]: Unify the file upload process , planned?

[mansiibm]

Hi LibreChat team, thank you for the amazing new features! I’m currently using LibreChat v0.8.1 and I’ve consistently noticed that the file upload process feels fragmented across different tools and file types.

Right now, as a user I have to remember:

1. For Excel / CSV files → I should use Code Interpreter
2. For .docx and similar documents → I should use File Search
3. For images, PDFs, and .txt → I can use “Upload as text” (OCR)
4. For provider uploads → I only see the “files supported by” each respective model

Because of this, it becomes cumbersome to remember which upload method to use for which file type.

Feature Request / Question

Would it be possible to have a unified file upload flow, where:

The user can simply drag-and-drop or select any file in one place, Libre Chat then automatically routes the file to the appropriate functionality (Code Interpreter, File Search, OCR, provider-specific handling, etc.), or

a. At least provides a single, guided dialog that:
b. Detects file type
c. Shows compatible actions (e.g., “Analyze with Code Interpreter”, “Index for File Search”, “Extract text with OCR”).
Applies sensible defaults based on file type

It will help in the following -

1. It reduces cognitive load for users (no need to remember which tool handles which file type).
2. Makes the UX feel more cohesive and beginner friendly.
3. Encourages users to explore more capabilities without worrying about choosing the “wrong” upload path.

Question

Is a unified file upload UX (with automatic routing or a single smart dialog) already planned on the roadmap?
If not, would this be something the team is open to considering?

Thanks again for all your work on LibreChat!

[malikmalikayesha]

I second @mansiibm on this! The upload button should be unified as a whole!

[bensi94]

I second this as well! Unifying would be much better experience.

[busla]

Thanks for raising this, and I want to echo support for a unified upload flow.

Since this discussion was opened, the options have been consolidated to just two: "Upload to provider" and "Upload as text". While fewer options sounds simpler, it arguably makes the UX more confusing — the labels are ambiguous and don't communicate what happens to the file or when to choose which. Users are left guessing.

From a UX standpoint, this still violates the principle of recognition over recall (Nielsen's heuristics) — users shouldn't need to maintain a mental mapping of file types to upload behaviors. In LibreChat's case, this means users should recognize the right action from clear, descriptive options at upload time, rather than recall from experience what "Upload to provider" vs "Upload as text" actually does for their specific file type.

That said, I want to give credit where it's due: the recent OCR implementation is a great step in the right direction. It already demonstrates the kind of intelligent routing this request is asking for — detecting image/PDF content and automatically extracting text. Extending that pattern to unify the upload experience feels like a natural evolution.

A few technical considerations that might help scope this:

1. Progressive disclosure — A single drop zone with a post-upload dialog showing detected type + available actions balances simplicity with power-user needs
2. Sensible defaults with override — Auto-route based on MIME type, but allow users to explicitly choose an alternative handler when needed
3. Consistent feedback — Unified upload should surface which tool is handling the file, so users learn the system over time without being blocked by it

This would bring LibreChat closer to the "invisible infrastructure" UX pattern — where the system handles complexity so users can focus on their actual task.

Happy to help test or provide feedback if this moves forward. Thanks again for all the work on LibreChat!

[aitp-john]

Agree with this feedback. Huge pain point for our users

[ppatayane]

technical_doc.pdf
[Unified File Upload (2).pptx](https://github.com/user-attachments/files/25575275/Unified

LibreChat.-.18.February.2026.1.mp4

.File.Upload.2.pptx)
Hi @danny-avila Could you pls check above proposal to potentially improve experience for user and let us know feedback ? Does it seem in order or any comments?

[MieszkoMakuch]

Fully agree with the Smart Default Logic direction proposed here. Here's how I think it should work in practice, ordered by what I see as highest impact.

---

1. Users shouldn't need to understand the upload paths

This isn't just a power-user vs. casual-user issue. The current labels ("Upload to provider" / "Upload as text" / "Upload for File Search") are unclear even for technical users. The distinction that actually matters is:

• Small files → injected into conversation context (full content, limited by token budget)
• Large files → indexed and semantically searched on demand (no token limit, but retrieval-based)

The current naming doesn't communicate this at all. And critically, there's no indication that file_search handles larger files better — you'd only know that from reading the docs.

2. The file_search toggle adds unnecessary friction

Right now to use file search, you have to: toggle file_search ON → click paperclip → click "Upload for File Search." If you skip the toggle, the option doesn't even appear.

This creates two problems:

• Users who toggle file_search ON may assume all their uploads are being searched — when in reality only files explicitly uploaded via "Upload for File Search" are.
• Users who don't toggle it never discover the feature exists.

If file_search is available in the system, it should just be part of the automatic routing — no separate toggle needed. The system should decide based on file size and type whether to use context injection or vector search. Requiring users to manually opt into file_search and then use a separate upload flow defeats the purpose of unification.

3. Default routing logic

The system should pick the best path automatically based on what's available:

• Images → if the endpoint supports images, send to model directly. If not, run OCR and inject extracted text into context.
• Non-image files → if file_search is available, embed in vector DB by default. If file_search is off, fall back to injecting text into context.

This covers the majority of cases without user intervention.

4. Silent truncation is a problem

When a file doesn't fit in context, fileTokenLimit silently truncates it. The user has no idea that a large portion of their document was cut off. At minimum there should be a visible warning: "This file was truncated to fit the context window. For full document search, enable file search." — or better yet, the system should auto-route to file_search when it detects the file won't fit.

5. Admin-configurable routing priority

The smart default logic should be configurable via librechat.yaml — e.g., an admin might want to force all files through context even when file_search is available, or always prefer RAG. Something like a priority list that defines the fallback chain per file type. Different deployments have different needs.

---

The key principle: the system should handle the complexity so users can focus on their task. Smart defaults with admin-level configuration covers both simplicity for end users and control for deployers.

[LouisLoyer]

Love this proposal — especially the focus on smart defaults and admin-level routing. Totally agree that users shouldn’t have to understand the different upload paths, and that the system should make the right choice between context injection and file_search automatically.

One additional angle that might be worth including is how uploads interact with the code interpreter / code execution tool.

Right now you’ve nicely covered:

• Small vs large files → context vs file_search

• Automatic routing based on size/type

• Admin-configurable priorities in librechat.yaml
  But there’s a third consumer of files in many setups: the code interpreter / sandboxed runtime (e.g. when the user says “analyze this CSV” or “run some Python on this file”). From a user’s perspective, when they upload a file, they often expect:

• The assistant to be able to talk about the content (context / RAG via file_search)

• And also to be able to manipulate the same file in code (via the code interpreter)
  → without having to upload or select it again via a different path.

It might be worth extending the smart routing logic so that, when the code interpreter is enabled:

• The same uploaded file can be registered both for file_search and made available in the code workspace (e.g. mounted as a file in the interpreter’s working directory).

• This behavior is also admin-configurable in librechat.yaml, e.g.:

• Always mirror uploads to code interpreter

• Only mirror certain types (.csv, .xlsx, .json, etc.)

• Or disable mirroring for security/compliance reasons

This would align really well with your key principle:
The system should handle the complexity so users can focus on their task.

From the user’s POV, there’s just “upload file once”, and the platform makes it available where it’s needed: conversation context, file_search, and (when enabled) the code interpreter.

[ppatayane]

File Unify Process.pdf
Iterating on suggestions. Please find new file.

[oleridd]

I second this proposal.

We have LibreChat deployed for a large government organization, and it works great! But the file upload system is causing complications and confusion.

Particular problems that we have encountered:

• It is difficult to teach our users with low technical competance the proper way to upload different file types. Some of them are not necessarily completely comfortable with file extensions, and struggle choosing between "Upload to provider", "Upload as text", and "Upload for file search"
• People using "Upload to provider" tend to overload our LLMs with tokens. The most appropriate option for users with very large documents is file search (which works great by the way) but the feature has a tendency to be "hidden away", since it has to be manually activated before the option showing up. We have considered removing "Upload to provider" in its entirety, but this does not seem to be possible as of now.
• "Upload as text" silently accepts incopmatible files. E.g. when uploading a PDF document, it will send meta information and raw data to the LLM and the user may think that the upload succeeded, but be confused as to why the LLM cannot read the file contents.

Currently, file uploads is the number one feature mentioned in our user feedback. I think it would be very useful to implement a user friendly consolidated flow.

[LeonardSEO]

Second this!

[danny-avila]

There’s an open PR for this I’m hoping to finalize this week

#12626

[kaeelo5]

Hi has this been fixed yet by any chance? I've just started using Librechat and like many, it's very confusing to know when to use what. Stumbled about this thread so hoping it's been fixed.