Help: Exporting for developer handoff - the SVG code is a mess of layers.

Yeah, that nested SVG export is a real headache for handoff. I've been there.

You're right about the IDs being a problem. Even if a dev manages to untangle the nesting, those generic IDs make it tough to apply consistent CSS later. Have you tried using the "Copy as SVG" option versus the direct download? Sometimes that yields slightly cleaner code, but it's still not great.

For icons, my workaround now is to run the Recraft SVG through a quick pass in SVGOMG. It usually strips out most of that unnecessary nesting and transforms the code into something a dev can actually work with. It's an extra step, but it saves everyone time in the end.

The nesting issue you're describing is a direct result of the editor preserving transform and group states for its own internal undo/redo stack. It's not just messy; it introduces real performance overhead. Each extra `g` element adds to the node count the browser has to reconcile, which can matter for a dashboard with a dozen icons.

While SVGOMG helps, it often doesn't fix the non-semantic ID problem. A more systematic fix is to process the exported file with SVGO using a custom config that adds `--pretty` and `--indent=2` for readability, and enables the `cleanupIDs` plugin with a `prefix` option. This lets you generate predictable, scoped IDs like `bell-` for your entire set in one batch step.

For your dev handoff, I'd also recommend exporting a single icon, processing it with that SVGO config, and sharing the terminal command or npm script as part of the handoff. It turns a manual cleanup into a reproducible build step.

You've perfectly diagnosed the core issue. This isn't just an aesthetic problem. That deep nesting and transform preservation creates a significant performance tax, especially in a dashboard context where these icons might be rendered dozens of times.

The generic IDs are a separate but critical flaw for maintainability. A developer can't write `#icon-bell { fill: var(--alert); }` when the target is `#layer_23_transform`. It forces them to either overwrite inline styles with `!important` or manually edit every file, which defeats the purpose of a handoff.

While post-processing with SVGO is essential, you should also audit the export settings within Recraft itself, if any exist. Some tools have a "flatten" or "export for code" option that reduces nesting before the file leaves the editor. If it's not there, consider it a missing feature and factor that into your tool evaluation for future projects.

The snippet you posted is a classic case of editor bloat. Each of those `` layers often carries a `transform` matrix, even if it's just `translate(0,0)`. That's the performance tax.

You need to flatten and clean. Use an SVGO config file. Don't just run the default optimization, it won't fix the ID problem. You need the `cleanupIDs` and `collapseGroups` plugins active. Here's a minimal config that works:

```json
{
"plugins": [
"cleanupIDs",
"collapseGroups",
"removeEmptyContainers"
]
}
```

Run your icons through that in a batch. It'll strip the nested groups and rename the IDs to something like `#a`, `#b`. It's not semantic, but it's predictable and flat. Your dev can then target the outer `` or wrap it for styling.

That's such a key point about tool evaluation. I've stuck with certain design tools longer than I should have because I loved the interface, but the export overhead created constant friction with our dev team. It feels like a hidden cost.

You mentioned looking for a "flatten" option, and I've seen that sometimes it's not a single checkbox, but a workflow. In some apps, you have to manually "Combine Paths" or "Flatten to Base Layer" *before* you even hit export. If Recraft has any kind of grouping or layer panel, that might be the manual step needed to strip out some of that nesting pre-export. Still, it shouldn't be necessary for a clean icon handoff, and that's a real mark against it.

You're right about the friction becoming a hidden cost in tool selection. I've seen teams build entire preprocessing pipelines just to clean up design exports, which adds complexity and potential failure points to the deployment process.

>The export overhead created constant friction with our dev team.

This is the exact metric I started using to evaluate tools. If the clean output requires a manual "flatten" step or a secondary toolchain, I factor that into the total time-to-production. For a dashboard with frequent icon updates, that overhead can quickly negate any speed gains from the design interface itself.

It often points to the tool prioritizing its own internal state management over the practical use case of shipping code.

You've hit on a key operational metric: the total friction in the deployment pipeline is a better evaluation criterion than the isolated efficiency of the design tool. I've advised teams to log the time spent on these post-processing steps; it often reveals that the "fast" tool is actually the bottleneck.

The prioritization of internal state over export integrity is a common architectural smell. It mirrors database systems that optimize for write performance but create unreadable, inefficient dumps - the technical debt has just moved from the application layer to the build process.

That's a really good point about the dev being forced into using `!important`. I hadn't even thought of that consequence. Makes the CSS a total mess.

I looked for a flatten option in Recraft but couldn't find one. It definitely feels like a missing feature. Makes me wonder if I should be looking at other tools for future projects, even if the design part is easier.

I've experienced that same friction from the other side, working on systems that integrated those processed assets. The manual "Combine Paths" step you described often fails as a one-off fix because designers forget to do it consistently before each export, which reintroduces the broken SVG structure in a later update.

It makes version control for icons much noisier, as the diff shows all the nesting changes instead of just the intentional design tweak.

Exactly right. The diff noise is a hidden cost that doesn't show up on a tool feature list. It erodes trust in the design-to-dev process because every PR for a minor icon tweak looks like a massive structural rewrite. It forces a review of the entire SVG instead of a quick check on the changed fill or path.

You can try to gate it with a pre-commit hook that runs SVGO, but then you're just automating the cleanup of a problem the tool created. It means your designers are effectively working in a source format, and the devs receive a compiled artifact. That's a broken pipeline.

If a tool can't export a clean, nearly-flat SVG by default, it's not a serious tool for production work.

The `!important` mess is exactly what happens when the tool's output fights the dev's workflow. It's not just messy CSS, it makes the whole component library brittle and hard to theme.

Your instinct about evaluating other tools is correct. If a tool's "easier" design phase creates a recurring cleanup tax for every export, it's not actually easier for the project. The total cost shifts to engineering.

Check if the tool has an API or plugin system. Sometimes the clean export is buried there, not in the UI, which is another red flag about their priorities.

Adding the terminal command or npm script to the handoff is such a smart move for collaboration. It shifts the process from a one-time cleanup to a shared, repeatable standard.

I've done something similar by including a small `package.json` script in the design system repo, like `"optimize-icons": "svgo -f ./src/icons --config ./svgo.config.js"`. It gives developers a single command to run, and new designers can see exactly what post-processing is expected.

Your point about scoped IDs with a prefix is key - it prevents collisions when multiple optimized SVGs end up in the same document.

Oh wow, that snippet is really eye-opening. I'm just starting to learn about SVG workflows for our Salesforce reports dashboards, and I never would have thought to check the exported code like that.

>Every element is wrapped in multiple `` tags, often 4-5 layers deep.

That sounds exactly like the kind of thing that would make a developer groan. I was thinking about using a similar tool for some simple icons, but if the output requires that much cleanup, maybe it's more trouble than it's worth for a project that needs regular updates.

Is there a setting in Recraft you've found for "export for web" or something similar, or is the messy code just the default?

Unfortunately, the messy nested `` structure is often the default. Many visual tools preserve every single grouping from the canvas, which maps directly to their internal layer panel but creates bloated, semantic-free output.

I haven't found a "web export" toggle in Recraft that flattens it. This is a fundamental architectural decision: the tool is preserving its entire edit history in the export for potential re-import, sacrificing code usability. For a Salesforce dashboard where icons are assets, not documents to be re-edited, that's the wrong trade-off.

You're right to question its value. If you're updating reports regularly, the manual cleanup per export becomes a significant tax. A tool that doesn't respect the final consumption format is building a pipeline on a shaky foundation.