Hello, I'm writing about this again after addressing the same issue several months ago. I encountered the same problem I previously described in another section, which has since been resolved. However, I found that adding large content to the ".../workspace/knowledge/xxxx" section causes the browser to freeze. I hope this can be fixed soon.
Check Existing Issues
I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.
Installation Method
Docker
Open WebUI Version
v0.5.20
Ollama Version (if applicable)
No response
Operating System
Windows 11
Browser (if applicable)
Chrome 134.0.6998.118
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 listed steps to reproduce the bug in detail.
Expected Behavior
• When placing the content into the specified box located at “…/workspace/knowledge/xxxx,” the system should be able to handle or process it without any issues.
Actual Behavior
• Even though a similar problem was previously resolved in another location, placing a large amount of content in “…/workspace/knowledge/xxxx” once again caused the same issue, indicating that the system cannot properly handle large data.
Steps to Reproduce
Select large-sized content.
Place these data in “…/workspace/knowledge/xxxx.”
Observe the system’s behavior; if the previously mentioned issue reoccurs, it indicates that large files cause the system to malfunction or fail to operate correctly.
Originally created by @chalitbkb on GitHub (Mar 26, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/12087
Hello, I'm writing about this again after addressing the same issue several months ago. I encountered the same problem I previously described in another section, which has since been resolved. However, I found that adding large content to the ".../workspace/knowledge/xxxx" section causes the browser to freeze. I hope this can be fixed soon.
### Check Existing Issues
- [x] I have searched the existing issues and discussions.
- [x] I am using the latest version of Open WebUI.
### Installation Method
Docker
### Open WebUI Version
v0.5.20
### Ollama Version (if applicable)
_No response_
### Operating System
Windows 11
### Browser (if applicable)
Chrome 134.0.6998.118
### 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 listed steps to reproduce the bug in detail.
### Expected Behavior
• When placing the content into the specified box located at “…/workspace/knowledge/xxxx,” the system should be able to handle or process it without any issues.
### Actual Behavior
• Even though a similar problem was previously resolved in another location, placing a large amount of content in “…/workspace/knowledge/xxxx” once again caused the same issue, indicating that the system cannot properly handle large data.
### Steps to Reproduce
1) Select large-sized content.
2) Place these data in “…/workspace/knowledge/xxxx.”
3) Observe the system’s behavior; if the previously mentioned issue reoccurs, it indicates that large files cause the system to malfunction or fail to operate correctly.
### Logs & Screenshots
### Additional Information
This is where I previously wrote about this issue. It might help you understand better.
https://github.com/open-webui/open-webui/issues/9166#issue-2823646320
expand the tool call (Click on the little drop down / expand)
then: 5) browser freezes
<!-- gh-comment-id:2757331356 -->
@Classic298 commented on GitHub (Mar 27, 2025):
I don't know if related, but if
1) you use native tool calling
2) call a tool
3) tool returns 100k tokens
4) expand the tool call (Click on the little drop down / expand)
then: 5) browser freezes
<!-- gh-comment-id:2757810125 -->
@gaby commented on GitHub (Mar 27, 2025):
This is similar to what happens with syntax highlighting.
Related https://github.com/open-webui/open-webui/discussions/11924
I’ve had a few users report something similar. It often is due to browser extensions they have enabled
<!-- gh-comment-id:2771631511 -->
@jrkropp commented on GitHub (Apr 2, 2025):
I’ve had a few users report something similar. It often is due to browser extensions they have enabled
@spammenotinoz commented on GitHub (Apr 23, 2025):
I have found three main causes, but typically only impacts a few users.
a) Uncompressed images (absolutely kill the performance, these can lock-up the entire system for all users). Forcing client side compression has been my saviour.
b) Browser extensions
c) Large conversations (the entire conversation is stored uncompressed in the browser, just the console logs alone impact the performance) and bounces between the user and the server. Using knowledge instead of pasting text helps a lot.
Mitigation: Improving the performance of the database via pooling, can have some benefit.
<!-- gh-comment-id:2824038355 -->
@spammenotinoz commented on GitHub (Apr 23, 2025):
I have found three main causes, but typically only impacts a few users.
a) Uncompressed images (absolutely kill the performance, these can lock-up the entire system for all users). Forcing client side compression has been my saviour.
b) Browser extensions
c) Large conversations (the entire conversation is stored uncompressed in the browser, just the console logs alone impact the performance) and bounces between the user and the server. Using knowledge instead of pasting text helps a lot.
Mitigation: Improving the performance of the database via pooling, can have some benefit.
I've got the logs for it. This issue occured when I accidentally pasted in a text dump of an executable. The console doesn't show any errors, but the UI hangs. Notice the huge content row. After waiting a very long time, however, the UI loads, but is still nearly unresponsive. localhost-1748793639320.log
<!-- gh-comment-id:2927462263 -->
@Monniasza commented on GitHub (Jun 1, 2025):
I've got the logs for it. This issue occured when I accidentally pasted in a text dump of an executable. The console doesn't show any errors, but the UI hangs. Notice the huge content row. After waiting a very long time, however, the UI loads, but is still nearly unresponsive.
[localhost-1748793639320.log](https://github.com/user-attachments/files/20541124/localhost-1748793639320.log)
@chrisoutwright commented on GitHub (Jul 10, 2025):
Can something be improved with long chats (happens faster with more models side-by-side) with the lag? After 30k with three models, it is nearly impossible to continue.
<!-- gh-comment-id:3058335025 -->
@chrisoutwright commented on GitHub (Jul 10, 2025):
Can something be improved with long chats (happens faster with more models side-by-side) with the lag? After 30k with three models, it is nearly impossible to continue.
The performance may be improved by capping all message lengths and loading only messages that are visible.
<!-- gh-comment-id:3061720207 -->
@Monniasza commented on GitHub (Jul 11, 2025):
The performance may be improved by capping all message lengths and loading only messages that are visible.
When I pasted about 843k tokens (≈4M characters) into a new note in Open WebUI, the tab locked up. Clicking on Stop did nothing, so I closed and reopened the tab, only to find the note still empty.
The same lockup issue occurs if I paste in a large amount of text into the search bar of the model selector.
And when I paste in a large amount of text into the text input field within a channel.
<!-- gh-comment-id:3621439462 -->
@silentoplayz commented on GitHub (Dec 7, 2025):
When I pasted about 843k tokens (≈4M characters) into a new note in Open WebUI, the tab locked up. Clicking on `Stop` did nothing, so I closed and reopened the tab, only to find the note still empty.
<img width="2558" height="493" alt="Image" src="https://github.com/user-attachments/assets/eabeb8b5-977f-4795-98e6-97944ccf0bbe" />
The same lockup issue occurs if I paste in a large amount of text into the search bar of the model selector.
<img width="2558" height="454" alt="Image" src="https://github.com/user-attachments/assets/a1b04bcf-84a9-40b5-92a1-6e394db1cfb0" />
And when I paste in a large amount of text into the text input field within a channel.
<img width="2558" height="1269" alt="Image" src="https://github.com/user-attachments/assets/340cd208-ce34-4560-ae78-f1a56efc4447" />
I can also confirm the issue reported by OP. My previous comment highlights three more areas in the UI where this lockup was found to occur.
<!-- gh-comment-id:3621449306 -->
@silentoplayz commented on GitHub (Dec 7, 2025):
I can also confirm the issue reported by OP. My previous comment highlights three more areas in the UI where this lockup was found to occur.
It seems the ui does not use virtual rendering for large text documents?
<!-- gh-comment-id:3949375204 -->
@neon12345 commented on GitHub (Feb 24, 2026):
It seems the ui does not use virtual rendering for large text documents?
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 @chalitbkb on GitHub (Mar 26, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/12087
Hello, I'm writing about this again after addressing the same issue several months ago. I encountered the same problem I previously described in another section, which has since been resolved. However, I found that adding large content to the ".../workspace/knowledge/xxxx" section causes the browser to freeze. I hope this can be fixed soon.
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.5.20
Ollama Version (if applicable)
No response
Operating System
Windows 11
Browser (if applicable)
Chrome 134.0.6998.118
Confirmation
README.md.Expected Behavior
• When placing the content into the specified box located at “…/workspace/knowledge/xxxx,” the system should be able to handle or process it without any issues.
Actual Behavior
• Even though a similar problem was previously resolved in another location, placing a large amount of content in “…/workspace/knowledge/xxxx” once again caused the same issue, indicating that the system cannot properly handle large data.
Steps to Reproduce
Logs & Screenshots
Additional Information
This is where I previously wrote about this issue. It might help you understand better.
https://github.com/open-webui/open-webui/issues/9166#issue-2823646320
@Classic298 commented on GitHub (Mar 27, 2025):
I don't know if related, but if
then: 5) browser freezes
@gaby commented on GitHub (Mar 27, 2025):
This is similar to what happens with syntax highlighting.
Related https://github.com/open-webui/open-webui/discussions/11924
@jrkropp commented on GitHub (Apr 2, 2025):
I’ve had a few users report something similar. It often is due to browser extensions they have enabled
@spammenotinoz commented on GitHub (Apr 23, 2025):
I have found three main causes, but typically only impacts a few users.
a) Uncompressed images (absolutely kill the performance, these can lock-up the entire system for all users). Forcing client side compression has been my saviour.
b) Browser extensions
c) Large conversations (the entire conversation is stored uncompressed in the browser, just the console logs alone impact the performance) and bounces between the user and the server. Using knowledge instead of pasting text helps a lot.
Mitigation: Improving the performance of the database via pooling, can have some benefit.
@Monniasza commented on GitHub (Jun 1, 2025):
I've got the logs for it. This issue occured when I accidentally pasted in a text dump of an executable. The console doesn't show any errors, but the UI hangs. Notice the huge content row. After waiting a very long time, however, the UI loads, but is still nearly unresponsive.
localhost-1748793639320.log
@chrisoutwright commented on GitHub (Jul 10, 2025):
Can something be improved with long chats (happens faster with more models side-by-side) with the lag? After 30k with three models, it is nearly impossible to continue.
@Monniasza commented on GitHub (Jul 11, 2025):
The performance may be improved by capping all message lengths and loading only messages that are visible.
@silentoplayz commented on GitHub (Dec 7, 2025):
When I pasted about 843k tokens (≈4M characters) into a new note in Open WebUI, the tab locked up. Clicking on
Stopdid nothing, so I closed and reopened the tab, only to find the note still empty.The same lockup issue occurs if I paste in a large amount of text into the search bar of the model selector.
And when I paste in a large amount of text into the text input field within a channel.
@silentoplayz commented on GitHub (Dec 7, 2025):
I can also confirm the issue reported by OP. My previous comment highlights three more areas in the UI where this lockup was found to occur.
@neon12345 commented on GitHub (Feb 24, 2026):
It seems the ui does not use virtual rendering for large text documents?