I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I am using the latest version of Open WebUI.
Installation Method
Git Clone
Open WebUI Version
0.6.34
Ollama Version (if applicable)
No response
Operating System
Windows 11
Browser (if applicable)
No response
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
I have a prompt for use with vision LLMs to quickly transcribe an image. I included {{CLIPBOARD}} in the prompt and I expand it quickly by typing /im[TAB] and it correctly puts the image there and it all works up until I try to send the message.
Actual Behavior
But I get: 'url' field must be a base64 encoded image.
However if I put the image manually with Ctrl-V and send it, there is no error. It only happens when I expand the prompt with {{CLIPBOARD}} in it.
Steps to Reproduce
Create a new prompt like "{{CLIPBOARD}} transcribe this image"
Copy some image in the clipboard
Expand the prompt with /name so you can see the image thumbnail indicating the image was pasted in the message
Send it to the (vision-enabled) LLM
Logs & Screenshots
Additional Information
No response
Originally created by @peter-ch on GitHub (Oct 19, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18425
### 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 am using the latest version of Open WebUI.
### Installation Method
Git Clone
### Open WebUI Version
0.6.34
### Ollama Version (if applicable)
_No response_
### Operating System
Windows 11
### Browser (if applicable)
_No response_
### 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
I have a prompt for use with vision LLMs to quickly transcribe an image. I included {{CLIPBOARD}} in the prompt and I expand it quickly by typing /im[TAB] and it correctly puts the image there and it all works up until I try to send the message.
### Actual Behavior
But I get: 'url' field must be a base64 encoded image.
However if I put the image manually with Ctrl-V and send it, there is no error. It only happens when I expand the prompt with {{CLIPBOARD}} in it.
### Steps to Reproduce
1. Create a new prompt like "{{CLIPBOARD}} transcribe this image"
2. Copy some image in the clipboard
3. Expand the prompt with /name so you can see the image thumbnail indicating the image was pasted in the message
4. Send it to the (vision-enabled) LLM
### Logs & Screenshots
<img width="807" height="426" alt="Image" src="https://github.com/user-attachments/assets/cfb132dc-8696-4a59-9c75-524291da2b35" />
### Additional Information
_No response_
GiteaMirror
added the bug label 2026-05-05 20:47:31 -05:00
This indeed does look like an issue that can be reproduced by another contributor and I, although, the error displayed in the chat is different. I was able to reproduce this issue on the latest dev branch commit using Firefox browser.
To reproduce this issue on Firefox:
Start with an image or a screenshot copied to your device's clipboard.
Create a new prompt using {{CLIPBOARD}} as the prompt content.
Start a new chat with a vision supported model.
Type /clipboard (or whatever you named the prompt as) and click on the Paste tooltip/popup that appears or do something like /clip[TAB] to auto-select the highlighted prompt.
Click on the Paste tooltip/popup that appears one more (again). Clicking on it the 2nd time gets it to paste the image I have in my clipboard to Open WebUI's input field.
Type a query and send the message with the image attached.
Observe the response error.
The following error can be spotted in the back-end terminal for Open WebUI:
2025-10-19 20:37:30.494 | DEBUG | open_webui.main:process_chat:1565 - Error processing chat payload: 400: illegal base64 data at input byte 4
Edit: The error received on the front-end (UI) during local development is different than on the dev branch.
<!-- gh-comment-id:3420033480 -->
@silentoplayz commented on GitHub (Oct 19, 2025):
This indeed does look like an issue that can be reproduced by another contributor and I, although, the error displayed in the chat is different. I was able to reproduce this issue on the latest `dev` branch commit using Firefox browser.
### To reproduce this issue on Firefox:
Start with an image or a screenshot copied to your device's clipboard.
1) Create a new prompt using `{{CLIPBOARD}}` as the prompt content.
<img width="2305" height="313" alt="Image" src="https://github.com/user-attachments/assets/eb98ea67-2295-49b0-890d-5e5cf2dac5ce" />
2) Start a new chat with a vision supported model.
3) Type `/clipboard` (or whatever you named the prompt as) and click on the `Paste` tooltip/popup that appears or do something like `/clip[TAB]` to auto-select the highlighted prompt.
<img width="364" height="216" alt="Image" src="https://github.com/user-attachments/assets/aa69a6bf-a05a-4799-be3f-63b263971f36" />
4) Click on the `Paste` tooltip/popup that appears one more (again). Clicking on it the 2nd time gets it to paste the image I have in my clipboard to Open WebUI's input field.
<img width="364" height="216" alt="Image" src="https://github.com/user-attachments/assets/013181bc-71a9-4c61-ab59-3bd843183fd3" />
5) Type a query and send the message with the image attached.
6) Observe the response error.
<img width="2307" height="526" alt="Image" src="https://github.com/user-attachments/assets/01748a33-624f-4c82-a9b6-2aac47e24c5e" />
### The following error can be spotted in the back-end terminal for Open WebUI:
```
2025-10-19 20:37:30.494 | DEBUG | open_webui.main:process_chat:1565 - Error processing chat payload: 400: illegal base64 data at input byte 4
```
Edit: The error received on the front-end (UI) during local development is different than on the `dev` branch.
<img width="831" height="662" alt="Image" src="https://github.com/user-attachments/assets/1274550b-afb0-417b-b502-500cfc6151ae" />
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @peter-ch on GitHub (Oct 19, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18425
Check Existing Issues
Installation Method
Git Clone
Open WebUI Version
0.6.34
Ollama Version (if applicable)
No response
Operating System
Windows 11
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
I have a prompt for use with vision LLMs to quickly transcribe an image. I included {{CLIPBOARD}} in the prompt and I expand it quickly by typing /im[TAB] and it correctly puts the image there and it all works up until I try to send the message.
Actual Behavior
But I get: 'url' field must be a base64 encoded image.
However if I put the image manually with Ctrl-V and send it, there is no error. It only happens when I expand the prompt with {{CLIPBOARD}} in it.
Steps to Reproduce
Logs & Screenshots
Additional Information
No response
@silentoplayz commented on GitHub (Oct 19, 2025):
This indeed does look like an issue that can be reproduced by another contributor and I, although, the error displayed in the chat is different. I was able to reproduce this issue on the latest
devbranch commit using Firefox browser.To reproduce this issue on Firefox:
Start with an image or a screenshot copied to your device's clipboard.
{{CLIPBOARD}}as the prompt content.Start a new chat with a vision supported model.
Type
/clipboard(or whatever you named the prompt as) and click on thePastetooltip/popup that appears or do something like/clip[TAB]to auto-select the highlighted prompt.Pastetooltip/popup that appears one more (again). Clicking on it the 2nd time gets it to paste the image I have in my clipboard to Open WebUI's input field.The following error can be spotted in the back-end terminal for Open WebUI:
Edit: The error received on the front-end (UI) during local development is different than on the
devbranch.@tjbck commented on GitHub (Nov 2, 2025):
Addressed in dev;
@silentoplayz commented on GitHub (Nov 3, 2025):
I can confirm it's been solved!