Embeds are the boxes bots use for anything longer than a sentence. They have hard character limits, and the failure mode is a rejected message rather than a truncated one — which is why the bug always appears with real data and never in testing.
The limits worth remembering
| Part | Maximum |
|---|---|
| Title | 256 characters |
| Description | 4096 characters |
| Fields | 25 per embed |
| Field name | 256 characters |
| Field value | 1024 characters |
| Footer text | 2048 characters |
| Everything in one embed, combined | 6000 characters |
| Embeds per message | 10 |
Discord rejects the whole message. If your bot builds an embed from a list that is usually short, the day someone has thirty items is the day the command stops working entirely — and if you are not logging errors, it fails silently. Truncate on your side, always.
Building embeds that survive real data
- Cut every string to its limit as you set it
One helper that trims to a maximum and adds an ellipsis, used everywhere, removes this entire category of bug.
- Paginate lists rather than growing them
Twenty-five fields is the wall. A list that could exceed it needs pages with buttons, not a bigger embed.
- Test with the largest realistic input
The longest username, the biggest inventory, the most items. Testing with «test» proves nothing about production.
- Log the rejection
Discord's error says which field was too long. That message is genuinely helpful and it is wasted if nothing writes it down.
The limits push you towards something that was already true: an embed with twenty-five fields is a wall of text nobody reads. If you are near the limit, the message is probably trying to do too much rather than needing more room.
Run the command against your largest realistic dataset and confirm the message sends, with visible truncation rather than an error.