jitsi.help
Talk to an engineer

Why are long Jitsi chat messages cut off?

By Jitsi Help engineering teamUpdated View as Markdown

Short answer

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]

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

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

Written by the Jitsi Help engineering team

Jitsi infrastructure engineers who deploy and run Jitsi Meet servers in production. Last updated . How we write our guides

Stuck on something this page does not cover? Ask a question below. Jitsi Help engineers read every one.

Did this fix it?

Something on this page is outdated or wrong?

Collect debug info

These commands gather what an engineer needs to diagnose a Jitsi server. Copy them, run them, and keep the output.

Terminal
# Run on the server, from your docker-jitsi-meet folder

# 1. Every service should be "running" (or "healthy")
docker compose ps

# 2. Which images and release tags are running
docker compose images

# 3. Recent logs from the core services
docker compose logs --tail=200 web prosody jicofo jvb

# 4. The settings most fixes depend on
grep -E '^(PUBLIC_URL|JVB_ADVERTISE_IPS|ENABLE_LETSENCRYPT|ENABLE_AUTH|AUTH_TYPE)=' .env

# 5. Is anything listening for media on UDP 10000?
sudo ss -ulnp | grep 10000

Installed with the Debian packages instead of Docker? Read the service logs with:

Terminal
sudo journalctl -u prosody -u jicofo -u jitsi-videobridge2 --since "1 hour ago"

Remove passwords, secrets and tokens before you share any output.

Send the output to an engineer

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.

Discussion

    Stuck, or would rather not do this by hand?

    Deploy it in one click

    A private Jitsi server in your own AWS account with SSL, your domain and optional recording, transcription and JWT. Free 15 minute trial.

    Start free trial

    Talk to a Jitsi engineer

    Setup, fixes, branding, recording, scaling. Tell us what is happening and we reply with a plan and a quote.

    Get expert help

    Related

    Recently updated