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 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
In the Chat interface:
When you send a prompt, then click the Edit icon, the input box should have exactly the same content that you sent previously.
When you send a prompt, then click the Copy icon, the copied text should match exactly what you sent previously.
Actual Behavior
In the Chat interface, at some point between when you send the prompt and when you click Edit or Copy, any double-newline (\n\n) has double spaces ( ) added before each newline.
Example:
Original prompt:
OS: Ubuntu Linux
Shell: zsh
Please write a command line cheat sheet for a Windows CMD user.
After clicking Edit or Copy:
OS: Ubuntu Linux
Shell: zsh
Please write a command line cheat sheet for a Windows CMD user.
Note the extra " " at the end of each line but the last.
Steps to Reproduce
Log into OpenWebui
Click your Username icon in the top-right
Click Settings
Click Interface
Turn off "Rich Text Input for Chat"
Click Save
Click the X to close the modal
Click New Chat
Enter a prompt which contains double-newlines
Hit Enter
Mouseover the message you sent
Click either the Edit icon or the Copy icon
Observe that the text does not match what you entered
Logs & Screenshots
No relevant browser console logs were emitted.
No relevant Python logs were emitted.
Screenshots are attached.
Prompt before clicking send:
Prompt after clicking send, before clicking edit. I've highlighted the text with the mouse. Note there are no extra spaces visible:
Prompt after clicking edit. I've highlighted the text with the mouse. Note the extra spaces:
Prompt after clicking edit. I've highlighted only the extra spaces at the end of one of the lines, to make it more clear:
Additional Information
The most recent version that doesn't have this bug is v0.6.28.
This also seems to happen when Rich Text Input is enabled, but I don't know if that's expected behavior with that feature.
Originally created by @bgreene2 on GitHub (Dec 27, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20198
### 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
Pip Install
### Open WebUI Version
v0.6.43
### Ollama Version (if applicable)
_No response_
### Operating System
Ubuntu 22.04 (Host)
### Browser (if applicable)
Chrome 143.0.7499.170 (Windows 11), Firefox 146.0.1 (Android)
### 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
In the Chat interface:
* When you send a prompt, then click the Edit icon, the input box should have exactly the same content that you sent previously.
* When you send a prompt, then click the Copy icon, the copied text should match exactly what you sent previously.
### Actual Behavior
In the Chat interface, at some point between when you send the prompt and when you click Edit or Copy, any double-newline (\n\n) has double spaces ( ) added before each newline.
Example:
Original prompt:
```
OS: Ubuntu Linux
Shell: zsh
Please write a command line cheat sheet for a Windows CMD user.
```
After clicking Edit or Copy:
```
OS: Ubuntu Linux
Shell: zsh
Please write a command line cheat sheet for a Windows CMD user.
```
Note the extra " " at the end of each line but the last.
### Steps to Reproduce
1. Log into OpenWebui
2. Click your Username icon in the top-right
3. Click Settings
4. Click Interface
5. Turn off "Rich Text Input for Chat"
6. Click Save
7. Click the X to close the modal
8. Click New Chat
9. Enter a prompt which contains double-newlines
10. Hit Enter
11. Mouseover the message you sent
12. Click either the Edit icon or the Copy icon
13. Observe that the text does not match what you entered
### Logs & Screenshots
* No relevant browser console logs were emitted.
* No relevant Python logs were emitted.
* Screenshots are attached.
Prompt before clicking send:
<img width="1200" height="428" alt="Image" src="https://github.com/user-attachments/assets/4275f4d4-c003-4122-b57c-125272561139" />
Prompt after clicking send, before clicking edit. I've highlighted the text with the mouse. Note there are no extra spaces visible:
<img width="1585" height="382" alt="Image" src="https://github.com/user-attachments/assets/0f747fb1-1660-4977-9120-43a860d3f5f7" />
Prompt after clicking edit. I've highlighted the text with the mouse. Note the extra spaces:
<img width="1529" height="459" alt="Image" src="https://github.com/user-attachments/assets/d7a3e14f-766c-4095-960c-c9998e7c256f" />
Prompt after clicking edit. I've highlighted only the extra spaces at the end of one of the lines, to make it more clear:
<img width="1548" height="419" alt="Image" src="https://github.com/user-attachments/assets/ba32d8eb-725a-4c0a-8da2-f0bf47381491" />
### Additional Information
* The most recent version that doesn't have this bug is v0.6.28.
* This also seems to happen when Rich Text Input is enabled, but I don't know if that's expected behavior with that feature.
#18161issue: v0.6.33 - Previous reply not sent with prompt by frenzybiscuit • Oct 08, 2025 • bug
#19078issue: Inconsistent default system prompt loading by abcbarryn • Nov 10, 2025 • bug
💡Tips:
If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
If you found a solution in any of these issues, please share it here to help others
This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
<!-- gh-comment-id:3693791742 -->
@owui-terminator[bot] commented on GitHub (Dec 27, 2025):
🔍 **Similar Issues Found**
I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:
1. [#20155](https://github.com/open-webui/open-webui/issues/20155) **issue:**
*by dhaern • Dec 24, 2025 • `bug`*
2. [#20107](https://github.com/open-webui/open-webui/issues/20107) **issue:**
*by mengdeer589 • Dec 22, 2025 • `bug`*
3. [#20196](https://github.com/open-webui/open-webui/issues/20196) **issue:**
*by dhaern • Dec 27, 2025 • `bug`*
4. [#19877](https://github.com/open-webui/open-webui/issues/19877) **issue:**
*by dotmobo • Dec 11, 2025 • `bug`*
5. [#19861](https://github.com/open-webui/open-webui/issues/19861) **issue:**
*by QuitHub • Dec 10, 2025 • `bug`*
<details>
<summary>Show 5 more related issues</summary>
6. [#19777](https://github.com/open-webui/open-webui/issues/19777) **issue:**
*by Yaute7 • Dec 05, 2025 • `bug`*
7. [#20019](https://github.com/open-webui/open-webui/issues/20019) **issue:**
*by j63440490 • Dec 17, 2025 • `bug`*
8. [#20092](https://github.com/open-webui/open-webui/issues/20092) **issue:**
*by VideoRyan • Dec 22, 2025 • `bug`*
9. [#18161](https://github.com/open-webui/open-webui/issues/18161) **issue: v0.6.33 - Previous reply not sent with prompt**
*by frenzybiscuit • Oct 08, 2025 • `bug`*
10. [#19078](https://github.com/open-webui/open-webui/issues/19078) **issue: Inconsistent default system prompt loading**
*by abcbarryn • Nov 10, 2025 • `bug`*
</details>
---
💡 **Tips:**
- If this is a duplicate, please consider closing this issue and adding any additional details to the existing one
- If you found a solution in any of these issues, please share it here to help others
*This comment was generated automatically by a bot.* Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
None of the issues found by the owui-terminator bot match this issue.
I never saw a single issue found by the owui-terminator bot match lol, worse bot ever
<!-- gh-comment-id:3693800268 -->
@dhaern commented on GitHub (Dec 27, 2025):
> None of the issues found by the owui-terminator bot match this issue.
I never saw a single issue found by the owui-terminator bot match lol, worse bot ever
I am able to reproduce this issue on the latest dev commit using Mozilla Firefox Snap for Ubuntu v146.0.1 (64-bit).
Prompt I copy/pasted:
OS: Ubuntu Linux
Shell: zsh
Please write a command line cheat sheet for a Windows CMD user.
After clicking Edit or Copy buttons to see the text:
OS: Ubuntu Linux
Shell: zsh
Please write a command line cheat sheet for a Windows CMD user.
Screenshots should be sufficient enough to prove this. Thanks for the report @bgreene2.
<!-- gh-comment-id:3694069968 -->
@silentoplayz commented on GitHub (Dec 27, 2025):
I am able to reproduce this issue on the latest `dev` commit using Mozilla Firefox Snap for Ubuntu v146.0.1 (64-bit).
Prompt I copy/pasted:
```
OS: Ubuntu Linux
Shell: zsh
Please write a command line cheat sheet for a Windows CMD user.
```
After clicking `Edit` or `Copy` buttons to see the text:
```
OS: Ubuntu Linux
Shell: zsh
Please write a command line cheat sheet for a Windows CMD user.
```
<img width="628" height="202" alt="Image" src="https://github.com/user-attachments/assets/37bb7f2f-2633-484b-a464-e3b450603ea6" />
<img width="631" height="292" alt="Image" src="https://github.com/user-attachments/assets/9a09ad10-5b62-45b2-afa8-fa55b3fb2fcd" />
<img width="631" height="292" alt="Image" src="https://github.com/user-attachments/assets/1ee4b193-bbd1-4e79-9866-5e80d60c5265" />
<img width="631" height="292" alt="Image" src="https://github.com/user-attachments/assets/27cb6bbc-ca94-4ab8-936c-07eb5533a5d9" />
<img width="631" height="292" alt="Image" src="https://github.com/user-attachments/assets/fbc44618-0a54-4935-8fdd-9921f7fffece" />
<img width="631" height="292" alt="Image" src="https://github.com/user-attachments/assets/a23f9c9b-4723-40ff-b063-8c4dce53f78c" />
<img width="631" height="292" alt="Image" src="https://github.com/user-attachments/assets/67076c76-0457-4336-a68f-b751ffd960d2" />
Screenshots should be sufficient enough to prove this. Thanks for the report @bgreene2.
I never saw a single issue found by the owui-terminator bot match lol, worse bot ever
To be fair, on stuff that's brand new, the bot obviously won't find anything like here.
<!-- gh-comment-id:3694078175 -->
@Classic298 commented on GitHub (Dec 27, 2025):
> I never saw a single issue found by the owui-terminator bot match lol, worse bot ever
To be fair, on stuff that's brand new, the bot obviously won't find anything like here.
yeah i wasted hours trying to fix this again, continuing my failed attempts from 5 days ago
i dont know how to fix this.
it seems the double spaces are needed, otherwise you get compatibility issues with github markdown rendering
there is a way to fix/remove the double new spaces of course, but then you introduce missing newlines as a new issue and fixing that is a whole different issue with richtextinput
<!-- gh-comment-id:3704092634 -->
@Classic298 commented on GitHub (Jan 1, 2026):
yeah i wasted hours trying to fix this again, continuing my failed attempts from 5 days ago
i dont know how to fix this.
it seems the double spaces are needed, otherwise you get compatibility issues with github markdown rendering
there is a way to fix/remove the double new spaces of course, but then you introduce missing newlines as a new issue and fixing that is a whole different issue with richtextinput
Conditionally Skip HTML-to-Markdown Conversion
Modify RichTextInput.svelte to respect the richText setting in onValueChange:
const onValueChange = () => {
if (!editor) return;
const jsonValue = editor.getJSON();
const htmlValue = editor.getHTML();
let mdValue;
if (richText) {
// Only convert HTML to markdown when rich text is enabled
mdValue = turndownService
.turndown(
(preserveBreaks ? htmlValue.replace(/<p><\/p>/g, '<br/>') : htmlValue).replace(
/ {2,}/g,
(m) => m.replace(/ /g, '\u00a0')
)
)
.replace(/\u00a0/g, ' ');
} else {
// For plain text, extract directly without HTML conversion
mdValue = editor.state.doc.textBetween(0, editor.state.doc.content.size, '\n');
}
This would bypass the space-adding turndown conversion when rich text is disabled.
Modify Turndown Configuration
Update the turndown service configuration to not add spaces around newlines:
// In RichTextInput.svelte#L33-L36, modify the turndown initialization
const turndownService = new TurndownService({
headingStyle: 'atx',
codeBlockStyle: 'fenced',
// Add option to preserve newlines without spaces
preformattedCode: true
});
Store Original Text Separately
Add a property to store the original unprocessed text:
// In the message object, store both processed and original text
{
content: processedContent, // For display
originalContent: originalContent // For edit/copy
}
This would preserve the original double newlines through the entire flow
NOTE: Solution 1 is the most targeted fix as it addresses the core issue: the HTML-to-markdown conversion happening when it shouldn't. It preserves the existing rich text functionality while fixing the plain text mode behavior.
<!-- gh-comment-id:3707084834 -->
@rgaricano commented on GitHub (Jan 3, 2026):
Even when Rich Text Input is turned off, the text still goes through HTML-to-markdown conversion that adds spaces around newlines. In `RichTextInput.svelte`, the `onValueChange` function processes all text through `turndownService` regardless of the rich text setting.
https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/common/RichTextInput.svelte#L1098-L1110
Solutions:
1. **Conditionally Skip HTML-to-Markdown Conversion**
Modify `RichTextInput.svelte` to respect the `richText` setting in `onValueChange`:
```
const onValueChange = () => {
if (!editor) return;
const jsonValue = editor.getJSON();
const htmlValue = editor.getHTML();
let mdValue;
if (richText) {
// Only convert HTML to markdown when rich text is enabled
mdValue = turndownService
.turndown(
(preserveBreaks ? htmlValue.replace(/<p><\/p>/g, '<br/>') : htmlValue).replace(
/ {2,}/g,
(m) => m.replace(/ /g, '\u00a0')
)
)
.replace(/\u00a0/g, ' ');
} else {
// For plain text, extract directly without HTML conversion
mdValue = editor.state.doc.textBetween(0, editor.state.doc.content.size, '\n');
}
```
This would bypass the space-adding turndown conversion when rich text is disabled.
2. **Modify Turndown Configuration**
Update the turndown service configuration to not add spaces around newlines:
```
// In RichTextInput.svelte#L33-L36, modify the turndown initialization
const turndownService = new TurndownService({
headingStyle: 'atx',
codeBlockStyle: 'fenced',
// Add option to preserve newlines without spaces
preformattedCode: true
});
```
3. **Store Original Text Separately**
Add a property to store the original unprocessed text:
```
// In the message object, store both processed and original text
{
content: processedContent, // For display
originalContent: originalContent // For edit/copy
}
```
Then use originalContent when editing or copying messages in https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/chat/Messages/UserMessage.svelte#L276-L280 and in https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/chat/Messages/ResponseMessage.svelte#L707-L711
4. **Preserve Double Newlines in Chat.svelte**
Remove the \n\n to \n conversion in the submit handlers:
In https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/chat/Chat.svelte#L2546 & in https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/chat/Chat.svelte#L2595
```
submitPrompt(e.detail) // Remove .replaceAll('\n\n', '\n')
```
This would preserve the original double newlines through the entire flow
**NOTE:** Solution 1 is the most targeted fix as it addresses the core issue: the HTML-to-markdown conversion happening when it shouldn't. It preserves the existing rich text functionality while fixing the plain text mode behavior.
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 @bgreene2 on GitHub (Dec 27, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20198
Check Existing Issues
Installation Method
Pip Install
Open WebUI Version
v0.6.43
Ollama Version (if applicable)
No response
Operating System
Ubuntu 22.04 (Host)
Browser (if applicable)
Chrome 143.0.7499.170 (Windows 11), Firefox 146.0.1 (Android)
Confirmation
README.md.Expected Behavior
In the Chat interface:
Actual Behavior
In the Chat interface, at some point between when you send the prompt and when you click Edit or Copy, any double-newline (\n\n) has double spaces ( ) added before each newline.
Example:
Original prompt:
After clicking Edit or Copy:
Note the extra " " at the end of each line but the last.
Steps to Reproduce
Logs & Screenshots
Prompt before clicking send:
Prompt after clicking send, before clicking edit. I've highlighted the text with the mouse. Note there are no extra spaces visible:
Prompt after clicking edit. I've highlighted the text with the mouse. Note the extra spaces:
Prompt after clicking edit. I've highlighted only the extra spaces at the end of one of the lines, to make it more clear:
Additional Information
@owui-terminator[bot] commented on GitHub (Dec 27, 2025):
🔍 Similar Issues Found
I found some existing issues that might be related to this one. Please check if any of these are duplicates or contain helpful solutions:
#20155 issue:
by dhaern • Dec 24, 2025 •
bug#20107 issue:
by mengdeer589 • Dec 22, 2025 •
bug#20196 issue:
by dhaern • Dec 27, 2025 •
bug#19877 issue:
by dotmobo • Dec 11, 2025 •
bug#19861 issue:
by QuitHub • Dec 10, 2025 •
bugShow 5 more related issues
#19777 issue:
by Yaute7 • Dec 05, 2025 •
bug#20019 issue:
by j63440490 • Dec 17, 2025 •
bug#20092 issue:
by VideoRyan • Dec 22, 2025 •
bug#18161 issue: v0.6.33 - Previous reply not sent with prompt
by frenzybiscuit • Oct 08, 2025 •
bug#19078 issue: Inconsistent default system prompt loading
by abcbarryn • Nov 10, 2025 •
bug💡 Tips:
This comment was generated automatically by a bot. Please react with a 👍 if this comment was helpful, or a 👎 if it was not.
@bgreene2 commented on GitHub (Dec 27, 2025):
None of the issues found by the owui-terminator bot match this issue.
@dhaern commented on GitHub (Dec 27, 2025):
I never saw a single issue found by the owui-terminator bot match lol, worse bot ever
@frenzybiscuit commented on GitHub (Dec 27, 2025):
Cannot replicate on the latest .43 using desktop firefox.
@silentoplayz commented on GitHub (Dec 27, 2025):
I am able to reproduce this issue on the latest
devcommit using Mozilla Firefox Snap for Ubuntu v146.0.1 (64-bit).Prompt I copy/pasted:
After clicking
EditorCopybuttons to see the text:Screenshots should be sufficient enough to prove this. Thanks for the report @bgreene2.
@Classic298 commented on GitHub (Dec 27, 2025):
To be fair, on stuff that's brand new, the bot obviously won't find anything like here.
@Classic298 commented on GitHub (Jan 1, 2026):
yeah i wasted hours trying to fix this again, continuing my failed attempts from 5 days ago
i dont know how to fix this.
it seems the double spaces are needed, otherwise you get compatibility issues with github markdown rendering
there is a way to fix/remove the double new spaces of course, but then you introduce missing newlines as a new issue and fixing that is a whole different issue with richtextinput
@rgaricano commented on GitHub (Jan 3, 2026):
Even when Rich Text Input is turned off, the text still goes through HTML-to-markdown conversion that adds spaces around newlines. In
RichTextInput.svelte, theonValueChangefunction processes all text throughturndownServiceregardless of the rich text setting.https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/common/RichTextInput.svelte#L1098-L1110
Solutions:
Modify
RichTextInput.svelteto respect therichTextsetting inonValueChange:This would bypass the space-adding turndown conversion when rich text is disabled.
Update the turndown service configuration to not add spaces around newlines:
Add a property to store the original unprocessed text:
Then use originalContent when editing or copying messages in https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/chat/Messages/UserMessage.svelte#L276-L280 and in https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/chat/Messages/ResponseMessage.svelte#L707-L711
Remove the \n\n to \n conversion in the submit handlers:
In https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/chat/Chat.svelte#L2546 & in https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/chat/Chat.svelte#L2595
This would preserve the original double newlines through the entire flow
NOTE: Solution 1 is the most targeted fix as it addresses the core issue: the HTML-to-markdown conversion happening when it shouldn't. It preserves the existing rich text functionality while fixing the plain text mode behavior.