Convert Discord Embeds to Components V2
A Components V2 migration is not a search-and-replace. Legacy content and embeds become a component tree, some visual conventions change, and a few old fields have no V2 equivalent. DWEEB's importer performs a conservative conversion and reports every compromise before you apply it.
How the conversion maps fields
| Legacy field | Components V2 result | Conversion note |
|---|---|---|
| content | Top-level Text Display | Prepended before converted embeds |
| embed title + URL | Markdown heading or linked heading | Preserves the visible title and link |
| embed description | Text Display | Preserves Discord markdown |
| embed colour | Container accent colour | Keeps the card-like visual identity |
| embed thumbnail | Section thumbnail accessory | Groups it with header and description |
| embed image | Media Gallery | Becomes full-width media |
| embed fields | Stacked Text Displays | Inline grids do not exist in V2 |
| footer + timestamp | Final Text Display | Preserved as readable text |
Fields that cannot map exactly
The importer does not hide lossy changes. Polls and stickers cannot accompany a V2 payload, so they are dropped with warnings. Embed video players and provider metadata have no equivalent. Author and footer names remain, but their inline icon URLs are omitted. Inline embed fields stack because Components V2 does not offer the old three-column field grid.
A very large embed can also exceed the 39-child Container ceiling or the 40-component message ceiling. DWEEB truncates only when required and adds a conversion note so you can split the result deliberately.
Convert a payload in DWEEB
- Open the builder's JSON panel and paste the complete legacy webhook payload.
- Read the conversion preview. Informational notes explain layout changes; warnings identify data with no V2 equivalent.
- Apply the conversion, then inspect each Container, Section and media block in the visual editor.
- Resolve validation issues and compare the result at desktop and narrow preview widths.
- Export the new JSON or send it only after the migration report is understood.
Before-and-after shape
// Legacy input
{
"content": "Release notes",
"embeds": [{
"title": "Version 2.4",
"description": "Faster search and a new dashboard.",
"color": 5793266,
"fields": [{ "name": "Fixed", "value": "Three permission bugs", "inline": true }]
}]
}
// V2 shape (editor ids omitted)
{
"flags": 32768,
"components": [
{ "type": 10, "content": "Release notes" },
{ "type": 17, "accent_color": 5793266, "components": [
{ "type": 10, "content": "## Version 2.4" },
{ "type": 10, "content": "Faster search and a new dashboard." },
{ "type": 10, "content": "**Fixed**\nThree permission bugs" }
]}
]
}Migration quality checklist
- Confirm that links, mentions and markdown still mean what they meant in the old message.
- Rework former inline fields for a single-column mobile layout instead of trying to imitate the old grid.
- Check image URLs and alt descriptions, especially for attachments that lived beside the original payload.
- Replace dropped polls, stickers or video-provider UI with explicit links or a separate message.
- For interactive additions, decide whether the destination must be app-owned before you send.
Put the guide into practice
Open the exact workflow in DWEEB. Nothing posts until you review and confirm it.
Open the JSON converter →