Slack Character Limit: Why 40,000 Is Technically Fine but 4,000 Is the Real Limit

Slack's API documentation states the technical ceiling plainly: 40,000 characters per message, tied to a 16-kilobyte payload limit enforced at the connection level. That's the number that actually blocks a message from sending. It's also almost never the number that matters, because long before a message gets anywhere near 40,000 characters, it stops being usable.

Why the Technical Limit Isn't the Practical One

Slack's own guidance recommends keeping messages under roughly 4,000 characters — a full order of magnitude below the hard cap. Past a certain length, Slack collapses a message into a truncated "Show more" snippet that has to be manually expanded, breaks code formatting, and turns tables into a single unreadable column on mobile. The message technically sent successfully; it just stopped functioning as a message anyone would actually want to read in the channel.

Different Fields, Different Limits

Beyond the standard channel message, Slack applies separate limits across other fields — block section text (used in more structured, app-generated messages) caps at 3,000 characters, and some direct message contexts allow up to 8,000. None of these numbers are interchangeable, and assuming one field's limit applies universally across Slack is a common way to hit an unexpected truncation.

A 40,000-character ceiling and a 4,000-character recommendation aren't really two versions of the same rule — one is what Slack's server will accept without disconnecting the client, and the other is what a human being will actually read without the message becoming a wall of collapsed text. Staying under the technical limit says nothing about whether the message still works.

What Actually Happens to an Oversized Message

A message that exceeds the practical, readable range doesn't get rejected — it gets buried. Slack folds it behind a "Show more" toggle, which most people simply scroll past rather than expand, and any code block inside it typically loses syntax highlighting once collapsed. For anything genuinely long — logs, detailed documentation, extended context — sharing a link to an external document works considerably better than pasting the full text directly into the channel, since it keeps the channel scannable and the content readable on both desktop and mobile.

What Actually Works Well

Slack's own data suggests the most effective messages run considerably shorter than even the 4,000-character soft limit — quick updates and questions in the 100-200 character range, more detailed status updates around 300-500, with anything longer split into a thread rather than a single dense message. Threading keeps a channel's main view scannable while still preserving room for a fuller conversation underneath.

Checking a Message Before Sending

Since the difference between a fine, readable message and one that collapses into an unreadable snippet comes down to a specific character count, checking a draft's length before sending — particularly for anything meant to include a code block, table, or detailed update — avoids finding out after the fact that it folded into a "Show more" toggle nobody expanded. A character counter makes that check immediate, without needing to estimate based on how a message looks while drafting it.

WhatsApp has a similar split between its technical ceiling and what a message should actually use — 65,536 characters allowed for personal messages, but WhatsApp Business templates get cut down to 1,024, with the recommended length running even shorter than that.

For a full side-by-side comparison with three other messaging platforms, Discord vs Slack vs WhatsApp vs Telegram breaks down how all four handle both the limit itself and what happens when a message goes over it.

---

Slack's 40,000-character technical limit and its roughly 4,000-character practical one aren't really in tension — they're answering different questions. One is what the server allows; the other is what a human reader will actually engage with rather than scroll past. Writing for the second number, not the first, is what keeps a message from technically sending successfully while functionally going unread.