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

[GH-ISSUE #19519] issue: Base64 encoded images included in API responses #34440

New Issue
Closed
opened 2026-04-25 08:26:34 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-25 08:26:34 -05:00
Owner
Copy Link

Originally created by @luke-wren on GitHub (Nov 26, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/19519

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.6.40

Ollama Version (if applicable)

No response

Operating System

Amazon Linux 2023

Browser (if applicable)

Chrome 142.0.7444.60

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

API responses that include user avatars should return a URL (or relative path) to the image, not an inlined base64 encoded image. This allows the browser and any intermediate caches to reuse the image rather than re-sending it on every request.

Several endpoints currently include a user object in their payloads. I would expect the profile_image_url field on that object to be a URL, similar to:

"user": {
"id": "c77a1139-75e1-4392-ab1c-1a2e8c69b086",
"name": "User",
"email": "user@example.com",
"role": "admin",
"profile_image_url": "/path/to/avatar.png"
}

For comparison, the model metadata returned from /api/v1/models/list already uses profile_image_url as a relative URL to an image, which is the behaviour I would expect for the user object as well.

Endpoints where I have observed this issue with the user object include:

  • /api/v1/tools
  • /api/v1/models
  • /api/v1/models/list
  • /api/v1/tools/list
  • /api/v1/prompts/list
  • /api/v1/knowledge/list
  • /api/v1/users

Actual Behavior

In API payloads, the user.profile_image_url field often contains a large base64 encoded image instead of a URL.

For users with high resolution avatars, this can inflate the response size significantly. In my case, some responses are over 23 MB purely due to repeated base64 avatar data.

Steps to Reproduce

These steps focus on /api/v1/models/list, but the behaviour is similar on other endpoints that include a user object.

  1. Run Open WebUI via Docker with the default configuration.
  2. Upload a custom avatar for your user.
    • Note: Open WebUI crops uploaded avatars to 250x250, but IdP synced avatars are not cropped.
  3. Create a model.
  4. Call the API: curl http://localhost:3000/api/v1/models/list
  5. Inspect the JSON response and observe that the user.profile_image_url field contains a large base64 encoded image instead of a URL.

Logs & Screenshots

Image

Additional Information

When a user uploads their own avatar, Open WebUI crops it to 250x250, which helps limit the maximum file size.

However, when user avatars are synced from a third party identity provider (Azure Entra ID in my case), they are not cropped. Some of these synced avatars are large (for example, 2000x2000), which results in very large base64 blobs being embedded into API responses wherever the user object is included.

This combination of uncropped high resolution avatars and base64 inlining in multiple endpoints leads to very large response sizes and unnecessary bandwidth usage.

Originally created by @luke-wren on GitHub (Nov 26, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/19519 ### 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.6.40 ### Ollama Version (if applicable) _No response_ ### Operating System Amazon Linux 2023 ### Browser (if applicable) Chrome 142.0.7444.60 ### 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 API responses that include user avatars should return a URL (or relative path) to the image, not an inlined base64 encoded image. This allows the browser and any intermediate caches to reuse the image rather than re-sending it on every request. Several endpoints currently include a user object in their payloads. I would expect the profile_image_url field on that object to be a URL, similar to: "user": { "id": "c77a1139-75e1-4392-ab1c-1a2e8c69b086", "name": "User", "email": "user@example.com", "role": "admin", "profile_image_url": "/path/to/avatar.png" } For comparison, the model metadata returned from /api/v1/models/list already uses profile_image_url as a relative URL to an image, which is the behaviour I would expect for the user object as well. Endpoints where I have observed this issue with the user object include: - /api/v1/tools - /api/v1/models - /api/v1/models/list - /api/v1/tools/list - /api/v1/prompts/list - /api/v1/knowledge/list - /api/v1/users ### Actual Behavior In API payloads, the user.profile_image_url field often contains a large base64 encoded image instead of a URL. For users with high resolution avatars, this can inflate the response size significantly. In my case, some responses are over 23 MB purely due to repeated base64 avatar data. ### Steps to Reproduce These steps focus on /api/v1/models/list, but the behaviour is similar on other endpoints that include a user object. 1. Run Open WebUI via Docker with the default configuration. 2. Upload a custom avatar for your user. • Note: Open WebUI crops uploaded avatars to 250x250, but IdP synced avatars are not cropped. 3. Create a model. 4. Call the API: curl http://localhost:3000/api/v1/models/list 5. Inspect the JSON response and observe that the user.profile_image_url field contains a large base64 encoded image instead of a URL. ### Logs & Screenshots <img width="938" height="1031" alt="Image" src="https://github.com/user-attachments/assets/22eb342c-8acc-4ff2-a754-7c3d112305a5" /> ### Additional Information When a user uploads their own avatar, Open WebUI crops it to 250x250, which helps limit the maximum file size. However, when user avatars are synced from a third party identity provider (Azure Entra ID in my case), they are not cropped. Some of these synced avatars are large (for example, 2000x2000), which results in very large base64 blobs being embedded into API responses wherever the user object is included. This combination of uncropped high resolution avatars and base64 inlining in multiple endpoints leads to very large response sizes and unnecessary bandwidth usage.
GiteaMirror added the bug label 2026-04-25 08:26:34 -05:00
GiteaMirror commented 2026-04-25 08:26:35 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Nov 27, 2025):

Should be addressed with 384753c6ca in dev!

<!-- gh-comment-id:3584000248 --> @tjbck commented on GitHub (Nov 27, 2025): Should be addressed with 384753c6cae0dec972e477ec7d94fa4849f52321 in dev!
GiteaMirror commented 2026-04-25 08:26:36 -05:00
Author
Owner
Copy Link

@silentoplayz commented on GitHub (Nov 30, 2025):

Can this be closed?

<!-- gh-comment-id:3592327955 --> @silentoplayz commented on GitHub (Nov 30, 2025): Can this be closed?
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#34440
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?