# Why are long Jitsi chat messages cut off?

> Check whether the text is shortened in your own input before sending. The reviewed Jitsi Meet 11248 web input clips a 910-character test string to 500 characters; upstream commit 052a654 removes that clipping. That fix is later than the reviewed 11248 source, so verify the deployed build instead of assuming an upgrade contains it. Network and provider limits are separate checks. [S1][S2][S3]

Source: https://jitsi.help/troubleshooting/jitsi-chat-message-cut-off/
Updated: October 24, 2026
Publisher: Jitsi Help (https://jitsi.help/)

## Locate where the text disappears

Use harmless test text and retain the original in a separate document. Recommended checks:

| Observation | Investigate |
| --- | --- |
| The end disappears immediately when pasted | Input/client truncation before transmission. [S2][S3] |
| Pasting works but editing an existing message shortens it | The version-specific message-correction path. [S2] |
| Your sender view is complete, but another client is not | Compare exact client builds, received text and display behavior before attributing a server limit. |
| Sending fails with an error rather than silently shortening text | Investigate that error and the actual server/provider policy; this is not automatically the same bug. |

The September 2026 report described clipped long text on meet.jit.si. Its login warning and guest-label observations were separate issues; one resolution should not be applied to all three. [S1]

## The confirmed source-level regression and fix

In pinned Jitsi Meet 11248 commit `f765042`, the web input's `_onMessageChange` stores `value.slice(0, CHAR_LIMIT)`. The corresponding constant is 500. The reviewed send/edit code also applies length slicing. [S3]

Upstream commit `052a6544ca08d3634e3c5c8de519a5d82fbd414f`, dated 28 September 2026, removes that slicing from web input and message-correction paths. Its rationale distinguishes this accidental web restriction from a native formatting optimization. [S2]

We executed the two actual input-handler bodies with a harmless 910-character string and a controlled state setter: the reviewed 11248 handler retained 500 characters; the fixed handler retained all 910. This proves that isolated input behavior, not delivery through a live conference. [S2][S3]

## Check your deployed client, not just the issue status

The upstream comparison places the fix after the reviewed 11248 source. That does not identify a later production release or prove the fix has reached your hosted service. [S2][S3]

Recommended operator workflow:

1. Record the actual running web release and the build served to a fresh browser using [the version guide](/guides/check-jitsi-version/).
2. Confirm whether that supported build contains the fix, including input, sent edits and received corrections. [S2]
3. If a supported update includes it, follow the normal [upgrade procedure](/guides/upgrade-jitsi-docker/) with backups and the matching release files. Package operators should verify the installed web build separately.
4. Repeat the harmless test in fresh sender and receiver clients. Compare the original, input, sent text and received text, including an edited message.

Do not switch production to an arbitrary development build or hand-edit a generated bundle solely because a commit exists. Plan an upgrade or supported patch with the operator.

## Temporary options for meeting participants

Until the deployed behavior is confirmed, keep the original text outside the chat, split a long post into numbered parts, and ask a recipient to confirm the last part arrived. If your organization has an approved document-sharing channel, share a permitted document there rather than repeatedly pasting truncated text.

These are workarounds, not proof that the underlying client was corrected. Raising a server limit cannot recreate text already removed before sending. [S2][S3]

## If the fixed client still loses text

Capture the exact client versions, whether this affects new messages or edits, and a harmless example with expected versus observed character counts. Distinguish stored text from rendering: a collapsed display is not necessarily missing data. Investigate the actual reported server/provider error where one exists; this review does not establish a universal stanza or service limit.

For an unrelated login prompt during the same meeting, use [authentication-session renewal](/troubleshooting/jitsi-authentication-session-expired/).

## Open questions and maintenance

Reviewed 24 October 2026. The isolated handler test did not send messages, compare native apps, validate a provider deployment or establish the first released package containing the fix. Confirm release inclusion and full sender/receiver behavior before marking a production incident resolved. Recheck the deployed code after upgrades. [S2][S3]

## Sources

- **[S1]** [Issue #17898](https://github.com/jitsi/jitsi-meet/issues/17898), September 2026 report and subsequent linked chat fix.
- **[S2]** Immutable [upstream correction](https://github.com/jitsi/jitsi-meet/commit/052a6544ca08d3634e3c5c8de519a5d82fbd414f), including input and correction changes, and [comparison with reviewed 11248](https://github.com/jitsi/jitsi-meet/compare/f765042bf280cbd7dcd4a9bbdb63b09e9e4d3259...052a6544ca08d3634e3c5c8de519a5d82fbd414f).
- **[S3]** Pinned 11248 [web input](https://github.com/jitsi/jitsi-meet/blob/f765042bf280cbd7dcd4a9bbdb63b09e9e4d3259/react/features/chat/components/web/ChatInput.tsx), [chat constants](https://github.com/jitsi/jitsi-meet/blob/f765042bf280cbd7dcd4a9bbdb63b09e9e4d3259/react/features/chat/constants.ts) and [message middleware](https://github.com/jitsi/jitsi-meet/blob/f765042bf280cbd7dcd4a9bbdb63b09e9e4d3259/react/features/chat/middleware.ts).

## Frequently asked questions

### Does Jitsi have a universal 500-character chat limit?

Do not treat it as a universal service policy. The reviewed web-client regression clips text to 500 characters, and an upstream fix removes that clipping. Other clients, servers or providers can have different limits.

### Which upstream change fixes the web-input clipping?

Commit 052a6544ca08d3634e3c5c8de519a5d82fbd414f removes the CHAR_LIMIT slicing from the web input and message-edit paths. Confirm that your supported deployed client contains that change before calling the issue fixed.

### Does the reviewed 11248 source already contain the fix?

No. The compared 11248 commit f765042 is an ancestor of the fix. Its tested input handler still stores only 500 characters from a 910-character string. A release name alone does not prove which web build clients receive.

### Can I use shorter messages while the operator investigates?

As a temporary workaround, divide the text into clearly numbered parts and check the received result. Keep the original elsewhere. Do not assume changing a server message-size limit can restore text already removed by the input.

### Is this the same as the authentication-session-expired warning?

No. Both appeared in one upstream report, but text truncation and login renewal are separate behaviors. Follow the dedicated session-expiry guide for a sign-in warning during a meeting.


---

Jitsi Help is an independent service. It is not affiliated with, endorsed by or sponsored by 8x8, Inc. or the Jitsi project. Jitsi and Jitsi Meet are trademarks of 8x8, Inc., used here only to describe the software we host and support.