github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 19:08:59 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #21598] bug: Images uploaded to chat are sent as file ID, not accessible URL, causing vision models to fail #58195

New Issue
Closed
opened 2026-05-05 22:31:16 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-05 22:31:16 -05:00
Owner
Copy Link

Originally created by @kpasechnikov2 on GitHub (Feb 19, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21598

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

0.8.2

Ollama Version (if applicable)

No response

Operating System

Ubuntu 22.04, browser upload (reproducible with Docker or git clone)

Browser (if applicable)

Chrome latest

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

When sending an image in chat (via browser upload), the image metadata's url property is only a file ID, not a full URL. As a result, when the chat message is sent to a vision model (e.g. GPT-4o, GPT-5.x, Azure, OpenAI etc), the backend/model cannot access the image and only gets the file ID, not the image bytes or a valid URL.

  • The current frontend code uploads successfully but records file.url=1465c96b-e52d-4b41-a06a-223144f838ae instead of /files/1465c96b-e52d-4b41-a06a-223144f838ae/content or a data:image/...;base64,... string.
  • When preparing the payload for the model, the code does not convert file IDs to retrievable URLs.
  • If you run a vision model (e.g. "GPT-4o") with an OpenAI-compatible backend (Azure, vLLM, Foundry, etc), you get a message like: I can help, but I need the actual image pixels to run OCR. The attachment you sent shows only a file reference (1465c96b-e52d-4b41-a06a-223144f838ae) and I can't access it from here.
  • This happens even though the frontend UI correctly reconstructs the file URL for displaying the image preview.

Actual Behavior

  • After uploading and sending an image, the model receives only a file ID as its url field, not a real URL or base64 image.
  • Vision models (Azure, GPT-4/5, etc) do not see an image at all because they cannot dereference the file id.
  • Human UI users can see the image, but vision LLMs cannot.
  • Workarounds (like uploading to a public server and pasting a real URL) do work, so this is a file reference/URL issue, not an auth/network issue.

Steps to Reproduce

  1. Start Open-WebUI (v0.8.2). Connect a vision-capable OpenAI-compatible model (Azure with vision, Foundry, vLLM+vision, etc)
  2. In chat, upload an image via the browser.
  3. Send message: "recognize text on this image"
  4. Model responds: "I can't access file attachment — only received reference ID, not actual image."
  5. Open the browser devtools and inspect the network/chat payload: the user message file block contains 
    "files": [{"type": "file", ... "url": "1465c96b-e52d-4b41-a06a-223144f838ae", ...}]
    instead of 
    "files": [{"type": "image", ... "url": "/files/1465c96b-e52d-4b41-a06a-223144f838ae/content", ...}]
    or... 
    "files": [{"type": "image", ... "url": "data:image/png;base64,...", ...}]
  6. As a result, vision models cannot "see" the uploaded image attachments and always reply needing a public link/base64 upload.

Logs & Screenshots

See network payload for file upload and final chat submission. Screenshot attached of model response:

I can help, but I need the actual image pixels to run OCR. The attachment you sent shows only a file reference (1465c96b-e52d-4b41-a06a-223144f838ae) and I can't access it from here.

Try with Azure Foundry, GPT-4o, vLLM, or any OpenAI-compatible vision endpoint. You will see only a file ID where a URL or image data is required.

Additional Information

How to fix:

  • When preparing messages with image/files for sending to the model, reconstruct the file URL using:
    • ${WEBUI_API_BASE_URL}/files/${file.url}/content if the URL is a file ID
    • Or, alternatively, upload as data URL if the provider supports inline base64 images
  • Ensure the model always receives a retrievable URL or base64-encoded image in the chat payload

References:

  • Frontend: src/lib/components/chat/Chat.svelte (code link)
  • UI reconstruction logic: src/lib/components/chat/MessageInput.svelte (code link)
Originally created by @kpasechnikov2 on GitHub (Feb 19, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/21598 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version 0.8.2 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 22.04, browser upload (reproducible with Docker or git clone) ### Browser (if applicable) Chrome latest ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior **When sending an image in chat (via browser upload), the image metadata's `url` property is only a file ID, not a full URL. As a result, when the chat message is sent to a vision model (e.g. GPT-4o, GPT-5.x, Azure, OpenAI etc), the backend/model cannot access the image and only gets the file ID, not the image bytes or a valid URL.** - The current frontend code uploads successfully but records file.url=`1465c96b-e52d-4b41-a06a-223144f838ae` instead of `/files/1465c96b-e52d-4b41-a06a-223144f838ae/content` or a `data:image/...;base64,...` string. - When preparing the payload for the model, the code does not convert file IDs to retrievable URLs. - If you run a vision model (e.g. "GPT-4o") with an OpenAI-compatible backend (Azure, vLLM, Foundry, etc), you get a message like: `I can help, but I need the actual image pixels to run OCR. The attachment you sent shows only a file reference (1465c96b-e52d-4b41-a06a-223144f838ae) and I can't access it from here.` - This happens even though the frontend UI correctly reconstructs the file URL for displaying the image preview. ### Actual Behavior - After uploading and sending an image, the model receives only a file ID as its `url` field, not a real URL or base64 image. - Vision models (Azure, GPT-4/5, etc) **do not see an image at all** because they cannot dereference the file id. - Human UI users can see the image, but vision LLMs cannot. - Workarounds (like uploading to a public server and pasting a real URL) do work, so this is a file reference/URL issue, not an auth/network issue. ### Steps to Reproduce 1. Start Open-WebUI (v0.8.2). Connect a vision-capable OpenAI-compatible model (Azure with vision, Foundry, vLLM+vision, etc) 2. In chat, upload an image via the browser. 3. Send message: "recognize text on this image" 4. Model responds: "I can't access file attachment — only received reference ID, not actual image." 5. Open the browser devtools and inspect the network/chat payload: the user message file block contains ```json "files": [{"type": "file", ... "url": "1465c96b-e52d-4b41-a06a-223144f838ae", ...}] ``` instead of ```json "files": [{"type": "image", ... "url": "/files/1465c96b-e52d-4b41-a06a-223144f838ae/content", ...}] ``` or... ```json "files": [{"type": "image", ... "url": "data:image/png;base64,...", ...}] ``` 6. As a result, vision models cannot "see" the uploaded image attachments and always reply needing a public link/base64 upload. ### Logs & Screenshots See network payload for file upload and final chat submission. Screenshot attached of model response: > I can help, but I need the actual image pixels to run OCR. The attachment you sent shows only a file reference (1465c96b-e52d-4b41-a06a-223144f838ae) and I can't access it from here. Try with Azure Foundry, GPT-4o, vLLM, or any OpenAI-compatible vision endpoint. You will see only a file ID where a URL or image data is required. ### Additional Information **How to fix:** - When preparing messages with image/files for sending to the model, reconstruct the file URL using: - `${WEBUI_API_BASE_URL}/files/${file.url}/content` if the URL is a file ID - Or, alternatively, upload as data URL if the provider supports inline base64 images - Ensure the model always receives a retrievable URL or base64-encoded image in the chat payload **References:** - Frontend: `src/lib/components/chat/Chat.svelte` ([code link](https://github.com/open-webui/open-webui/blob/main/src/lib/components/chat/Chat.svelte#L792-L825)) - UI reconstruction logic: `src/lib/components/chat/MessageInput.svelte` ([code link](https://github.com/open-webui/open-webui/blob/main/src/lib/components/chat/MessageInput.svelte#L1195-L1214))
GiteaMirror added the bug label 2026-05-05 22:31:16 -05:00
GiteaMirror commented 2026-05-05 22:31:19 -05:00
Author
Owner
Copy Link

@pr-validator-bot commented on GitHub (Feb 19, 2026):

⚠️ Missing Issue Title Prefix

@kpasechnikov2, your issue title is missing a prefix (e.g., bug:, feat:, docs:).

Please update your issue title to include one of the following prefixes:

  • bug: Bug report or error you've encountered
  • feat: Feature request or enhancement suggestion
  • docs: Documentation issue or improvement request
  • question: Question about usage or functionality
  • help: Request for help or support

Example: bug: Login fails when using special characters in password

<!-- gh-comment-id:3926602133 --> @pr-validator-bot commented on GitHub (Feb 19, 2026): # ⚠️ Missing Issue Title Prefix @kpasechnikov2, your issue title is missing a prefix (e.g., `bug:`, `feat:`, `docs:`). Please update your issue title to include one of the following prefixes: - **bug**: Bug report or error you've encountered - **feat**: Feature request or enhancement suggestion - **docs**: Documentation issue or improvement request - **question**: Question about usage or functionality - **help**: Request for help or support Example: `bug: Login fails when using special characters in password`
GiteaMirror commented 2026-05-05 22:31:20 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Feb 19, 2026):

fixed in 0.8.3 read the changelog, also duplicate issue use the search

<!-- gh-comment-id:3926630746 --> @Classic298 commented on GitHub (Feb 19, 2026): fixed in 0.8.3 read the changelog, also duplicate issue use the search
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#58195
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?