[GH-ISSUE #20198] issue: After sending a prompt, extra spaces are added #19121

New Issue

GiteaMirror · 2026-04-20T01:26:45-05:00

GiteaMirror commented

2026-04-20 01:26:45 -05:00

Originally created by @bgreene2 on GitHub (Dec 27, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20198

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

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

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.

GiteaMirror added the confirmed issue bug labels 2026-04-20 01:26:45 -05:00

GiteaMirror commented

2026-04-20 01:26:46 -05:00

@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 • bug

Show 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:

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.

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

GiteaMirror commented

2026-04-20 01:26:47 -05:00

@bgreene2 commented on GitHub (Dec 27, 2025):

None of the issues found by the owui-terminator bot match this issue.

@bgreene2 commented on GitHub (Dec 27, 2025): None of the issues found by the owui-terminator bot match this issue.

GiteaMirror commented

2026-04-20 01:26:47 -05:00

@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

@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

GiteaMirror commented

2026-04-20 01:26:48 -05:00

@frenzybiscuit commented on GitHub (Dec 27, 2025):

Cannot replicate on the latest .43 using desktop firefox.

@frenzybiscuit commented on GitHub (Dec 27, 2025): Cannot replicate on the latest .43 using desktop firefox.

GiteaMirror commented

2026-04-20 01:26:48 -05:00

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

Screenshots should be sufficient enough to prove this. Thanks for the report @bgreene2.

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

GiteaMirror commented

2026-04-20 01:26:48 -05:00

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

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

GiteaMirror commented

2026-04-20 01:26:49 -05:00

@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

@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

GiteaMirror commented

2026-04-20 01:26:49 -05:00

@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.
6f1486ffd0/src/lib/components/common/RichTextInput.svelte (L1098-L1110)

Solutions:

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
}

Then use originalContent when editing or copying messages in 6f1486ffd0/src/lib/components/chat/Messages/UserMessage.svelte (L276-L280) and in 6f1486ffd0/src/lib/components/chat/Messages/ResponseMessage.svelte (L707-L711)

Preserve Double Newlines in Chat.svelte
Remove the \n\n to \n conversion in the submit handlers:
In 6f1486ffd0/src/lib/components/chat/Chat.svelte (L2546) & in 6f1486ffd0/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.

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

GiteaMirror referenced this issue

2026-04-20 05:45:21 -05:00

[PR #19122] [MERGED] fix: Duplicate instructions in tool selection calling prompt #25097

GiteaMirror referenced this issue

2026-04-25 08:14:48 -05:00

[GH-ISSUE #19121] issue: Duplicate instructions in tool selection calling prompt #34307

GiteaMirror referenced this issue

2026-04-25 13:11:22 -05:00

[PR #19122] [MERGED] fix: Duplicate instructions in tool selection calling prompt #40727

GiteaMirror referenced this issue

2026-04-29 23:40:47 -05:00

[PR #19122] [MERGED] fix: Duplicate instructions in tool selection calling prompt #48145