Why Embed Limits Matter Before You Publish
Discord embed payloads often look fine until one field quietly crosses a character limit or one message tries to carry too many embeds or buttons at once.
That usually shows up late, after the copy is written. Catching the structure early saves cleanup time and avoids broken announcements.
- One field that is too long can invalidate an otherwise good payload.
- Total message budget matters, not just one title or description.
- Buttons and action rows also have structural limits worth checking before launch.
The Core Text Limits to Remember
The highest-signal limits are usually title length, description length, footer length, author name length, and field name/value length. Those are the points where rich messages break most often.
There is also a combined text budget across embeds in the same message, so splitting content across multiple embeds is not a free way around the limits.
- Titles stay short and scannable.
- Descriptions carry the largest text block but still have a ceiling.
- Fields are powerful, but each field name and value has its own cap.
- Combined embed text still needs a final budget check.
The Actual Limits, in Numbers
Here are the exact caps Discord enforces on a single embed. The title is capped at 256 characters, the description at 4,096, each field name at 256 and each field value at 1,024, the footer text at 2,048, and the author name at 256. An embed can hold at most 25 fields, and a single message can carry up to 10 embeds.
The limit that catches people is the combined one: across every embed in the same message, the total text in titles, descriptions, field names, field values, footers, and author names cannot exceed 6,000 characters. So a message with one 4,096-character description has only about 1,900 characters left for everything else, no matter how you spread it across embeds. Going over any single cap, or the 6,000 total, makes the whole payload fail rather than truncating politely.
- Title 256 · Description 4,096 · Field name 256 · Field value 1,024 · Footer 2,048 · Author 256.
- Up to 25 fields per embed, and up to 10 embeds per message.
- Combined cap: 6,000 characters across all embeds in one message — over the limit means rejected, not trimmed.
Multiple Embeds and Buttons Need Structure
Multiple embeds help when one card becomes too dense, but they still need hierarchy. Readers should understand why there is a second embed instead of one oversized block.
Buttons should serve one clear next action each. Too many buttons or mixed priorities make the payload harder to scan.
- Use multiple embeds to separate overview, details, and follow-up action.
- Keep button rows focused on a small set of clear actions.
- Treat buttons as workflow steps, not decoration.
A Practical Publishing Checklist
Before you post a webhook payload, review content hierarchy first and limits second. A payload that passes limits but reads poorly still creates support and moderation overhead.
The easiest workflow is to draft the copy, attach fields and buttons, then run one final review for length, structure, and action clarity.
- Check one embed at a time for title, description, author, footer, and fields.
- Then check the message as one combined payload.
- Finally, verify that buttons point to the right next action.
When to Split One Payload Into Several Parts
Not every webhook message should become a bigger embed stack. If readers need different actions at different times, one oversized payload can be harder to scan than two smaller posts or one embed plus a follow-up message.
Splitting the communication is often the better choice when the message mixes status, explanation, changelog detail, and multiple calls to action in one place.
- Keep one embed when the message supports one clear task or update.
- Use multiple embeds only when each embed has a distinct job, such as summary first and details second.
- Prefer a follow-up message when the extra information would distract from the main action.
- Recheck button purpose after splitting so each action row still feels obvious.