Rather than turning every icon into a lone Icon widget wrapped in containers, the converter recognises the shape of the block and picks the widget an experienced Elementor user would pick.
Pattern 1 — Icon Box
A container holding exactly one heading, one paragraph and at least one icon, with no other content elements (no images, buttons, lists, tables or forms), is converted to a single Icon Box widget.
What comes across: the icon itself, the title and description text, the heading level, text alignment, icon size, the spacing between icon and title, the gap under the title, and the typography and colours of both title and description. The card’s own frame — background, border, radius, shadow, padding — is written onto the widget’s Advanced settings, so no extra wrapper Container is created.
Pattern 2 — Icon List
A container whose children are two or more repeated rows, each with exactly one icon plus text (and no headings, images or buttons), becomes one Icon List widget with one editable item per row.
A nice detail: if every row uses the same source icon — the typical checkmark list — a single icon is chosen for all rows instead of guessing a different icon per row from the text. Unrecognised check marks fall back to fa-check. Spacing between rows, icon size, icon colour, text colour and text typography all transfer.
Pattern 3 — a plain Icon
Anything else that is just an icon becomes an Icon widget, sized and coloured from the source.
Getting icons into the Elementor icon library
Set the Icons option to Match Elementor icon library. Then:
- If your markup already uses Font Awesome classes (
<i class="fas fa-shield-alt">), that exact icon is used. - If it is an unnamed inline
<svg>, the converter matches by meaning — using the icon’s class, aria-label, title and the card’s heading text — against a keyword table (shield → shield, recycle/reusable → recycle, water/clean → tint, and so on). - If nothing matches, the icon control is left empty on purpose so you can pick one from Elementor’s icon picker rather than getting a wrong guess.
Why a card you expected to become an Icon Box did not
This is the question that brings people to this page, and the answer is almost always the same: the card contains a link.
The Icon Box test disqualifies a container holding any of these — a link, a button, an image, a list, a table, a form, an input, a select, a textarea, a video or an iframe. A feature card with a “Learn more” link at the bottom trips the very first one, and converts as a Container holding separate widgets instead.
That is deliberate rather than an oversight. Elementor’s Icon Box widget holds an icon, a title and a description — and that is all. Flattening a card that also contains a link would mean either dropping the link or smuggling it somewhere it does not belong. Neither is acceptable, so the tool declines to flatten and gives you the faithful version.
If you want the tidy Icon Box output, the fix is at the source: make the whole card clickable by wrapping it from outside, or drop the inner link and add an Elementor Button afterwards. If you would rather keep the link, the Container version is perfectly good — it is just one level deeper.
The same principle, shown more clearly by Image Box
The Image Box pattern — one image, one heading, up to one paragraph — carries a guard worth describing, because it shows the rule the whole converter is built on.
Before flattening, it compares the card’s total text against the heading text plus the paragraph text. If there is any text left over, the card is not converted to an Image Box.
The case this catches is the numbered step card: a big “1”, a heading and a description. It looks exactly like an Image Box candidate, but the Image Box widget has nowhere to put the “1” — flatten it and the number silently disappears. The comparison catches the leftover text and the card stays a Container, where every piece survives.
Losing content silently is the worst failure a conversion tool can have, because you only discover it much later, in front of someone else. Producing a slightly deeper tree is a cheap price for never doing that.
Why inline SVG is worth avoiding
A hand-drawn inline SVG cannot be placed into Elementor’s icon control. Worse, an SVG that relied on page CSS for its size and stroke (for example width:22px; stroke:currentColor; fill:none) loses that CSS once it is lifted out of the page — it can render at its default size with a solid black fill. That is the classic “my small check marks became huge black shapes” symptom.
Two ways to avoid it: use Font Awesome classes in the source, or let the Icon List / Icon Box detection replace the SVG with a real library icon. Unmatched inline SVGs that stay as HTML are at least written out at their rendered size so they cannot explode.