Migrating XD Components and Symbols to Figma Components — A Complete Guide

“States from my XD components didn’t translate cleanly into Variants.” “The master-instance relationship broke.” “Overrides I set on instances didn’t carry over.” — Component fidelity tends to be the last and hardest piece of XD → Figma migration.

XD and Figma share the surface concept of “components,” but their design philosophies diverge in important ways, and some details can’t be reproduced through automatic conversion alone. The valuable upfront work is knowing what conversion handles automatically and what needs a manual pass.

This article walks through how XD components map to Figma Components, how Pixel Fine Converter automatically converts them, which cases still need manual fixes, and the best practices that reduce friction.

What you’ll get from this article

• The core conceptual differences between XD and Figma components
• The mapping for masters / instances / states / overrides
• The scope of Pixel Fine Converter’s automatic conversion and the cases requiring manual cleanup
• Best practices — what to tidy on the XD side before converting

📝 Introduction — Why component migration is the hardest part

Designers who’ve used both tools share a familiar observation: components in XD and Figma feel different even though both rely on a master + instance model. The differences are concentrated in three places:

• How much structural change instances are allowed (XD permits adding / removing nodes; Figma does not)
• How states are handled (XD nests multiple states inside one master; Figma groups separate components into Variants)
• The granularity of overrides (text / image / color / nested behavior)

These three differences create “the wall that automatic conversion can’t cross,” and they tend to surface as the residual adjustment work at the end of every migration.

One thing to flag upfront: Component conversion is a feature of Pixel Fine Converter’s Pro plan (one-time $29). The plugin itself installs for free, but the Free plan covers structure / styles / groups; Components and Variants conversion are gated to Pro.

🔬 XD components vs Figma Components — the conceptual differences

What XD and Figma both call “components” are similar on the surface but materially different underneath. Three angles bring the differences into focus.

Masters and instances (basic structure)

Both tools have the master (definition) + instance (copy) structure, but what you’re allowed to do on the instance side is fundamentally different.

→ This “XD’s flexibility vs Figma’s strictness” is the single biggest obstacle in component conversion. The more a team relied on adding or removing nodes within XD instances, the more elements simply can’t be carried over structurally into Figma.

States vs Variants (multi-state management)

XD states (hover / pressed / disabled etc.) and Figma Variants both manage multiple states, but their internal structure differs.

Figma’s model is more expressive, which means conversion has to address “how do XD’s states map onto Variant property axes?” Pixel Fine Converter takes the direct route — it carries XD state names over as State=<state name> property values, so multi-axis reorganization (e.g. splitting into State + Size) is a manual step after conversion.

Overrides (text / image / color)

Both tools let instances override individual text / image / color values. The coverage differs.

→ Figma covers a broader range of override types, but there’s an asymmetry: “XD overrides that involve structural change can’t be brought into Figma as-is.” That asymmetry is the core problem behind Case 2 in Cases that need manual fixes.

🗺️ XD → Figma conversion mapping (how PFC behaves)

Pixel Fine Converter applies the following mapping rules when converting XD’s component-related elements into Figma.

Basic mapping: Master → COMPONENT, Instance → INSTANCE

This is the simplest conversion path. Master + instance groups with matching structure carry over automatically.

States → Variants conversion

XD masters with states become a Figma Component Set (COMPONENT_SET), with each state mapped to a State=<state name> Variant property value.

→ Interactive components that lean on states (buttons / toggles / chips) become Variants automatically as long as the structure matches. Prototype state-transition triggers are also converted into Variants switches where the data supports it.

Override preservation

Pixel Fine Converter brings overrides on XD instances (text / color / image / visibility) into Figma using a selective deep merge.

• Primitive values (color, opacity, text content) take the instance’s value
• Structural metadata (node type, constraints, layout info) takes the master’s value

This handles cases like “an XD rounded rectangle becomes a mask group on an instance” — overwriting structural metadata directly would violate Figma’s INSTANCE constraints, so we keep structural metadata on the master side intentionally. For full detail, see Features: Components.

Instance resizing

When an XD instance has different dimensions from its master, the Figma instance is resized to match the source. The tolerance is configurable in three steps — Strict (5px) / Standard (10px, default) / Tolerant (30px) — and Standard handles most cases accurately.

🛠️ Cases that need manual fixes

These are the cases that automatic conversion can’t fully cover, along with how to approach each one.

Case 1: Nested components

Components that contain other components — deeply layered hierarchies.

• Symptom: inner instances lose recognition accuracy or get flattened into individual frames
• Why: nesting depth accumulates tolerance error during structure matching, and parent changes ripple wider
• Approach:
  • Shallow nests usually work fine with “convert as-is, then visually verify in Figma”
  • Deep nests benefit from flattening the nesting in XD beforehand, or reorganizing into Component → Variant structure in Figma after conversion

Case 2: Overrides that involve structural changes

XD lets instances add or remove nodes; Figma’s INSTANCE doesn’t generally allow structural change.

• Symptom: the affected instance is converted as a plain Frame (not an INSTANCE), and the master link is lost
• Why: Figma’s INSTANCE model is designed not to permit structural change
• Approach:
  • The visuals are preserved, so leaving it as a Frame is often a practical choice
  • To keep the component reference, carve the “diverged instance” out as a separate master in XD before converting

Case 3: States with ambiguous boundaries

When XD states aren’t defined along explicit property axes, mapping them into Figma Variants isn’t always obvious.

• Symptom: states are converted as a flat enumeration (State=A / State=B / State=C) and need axis reorganization afterward
• Why: Figma Variants support multiple property axes (State + Size + Theme etc.), but XD states are a single-axis list
• Approach: after conversion, manually reorganize Variant property axes in Figma (e.g. split into a State axis + Size axis)

Case 4: Large components (500+ nodes)

For components above 500 nodes, Pixel Fine Converter applies a memory-conscious fallback to avoid OOM in the Figma plugin runtime — the authoritative default state extraction is skipped to stay within Figma’s plugin memory budget.

• Symptom: Variants are still generated, but the Default state may include residual state-based overrides (e.g. opacity adjustments left over from a specific state) rather than a clean authoritative default
• Approach: reduce node count (remove unused layers, merge vectors) so the component falls under 500 nodes, or split a single large component into smaller ones

⭐ Best practices for a smooth migration

A few things you can tidy on the XD side before converting will measurably improve fidelity on the Figma side.

1. Unify master naming

If XD masters are named haphazardly (Component 1 / New symbol etc.), it becomes hard to tell which master does what in Figma. Slash-delimited, meaningful names like Button/Primary or Card/Article map naturally onto Figma Variants conventions.

2. Standardize state naming

When state ordering and naming follow conventions (Default / Hover / Pressed / Disabled in English, in standard order) on the XD side, the resulting Figma State=Hover values come out meaningful and consistent.

3. Minimize nesting depth

As a rule of thumb, keeping component-within-component nesting shallow (2-3 levels) improves recognition accuracy after conversion. For deep nests, decomposing into simpler components on the XD side or reorganizing with an Atomic Design-style hierarchy in mind pays off as migration prep work.

4. Decompose structurally divergent instances ahead of time

“Instances whose structure diverges significantly from their master” can’t carry over to Figma (→ Case 2). Carving such instances out as separate masters in XD ahead of migration preserves the component reference on the Figma side too.

5. Clean up XD’s Document Assets

Unused assets / duplicated masters / leftover entries from rename history that were never tidied up turn into noise during conversion. Tidying Document Assets before migration reduces the component count carried into Figma and makes subsequent work simpler.

💬 Frequently asked questions

Q: Do XD states convert directly to Figma Variants?

A: For the most part, yes. XD states come in as State=<state name> property values in the Figma Component Set (Variants). That said, if you want a multi-axis property structure (e.g. three axes: State + Size + Theme), you’ll need to reorganize manually in Figma after conversion.

Q: If I edit the master in XD afterward, does it propagate to instances on the Figma side?

A: No — the two are unlinked after conversion. Once data is in Figma, XD and Figma are treated as fully independent files; you’d need to re-convert to reflect XD-side changes. Pixel Fine Converter isn’t designed for “continuously edit in XD and sync to Figma” workflows — it’s a migration tool, not a sync tool.

Q: Do nested components convert correctly?

A: Many do, but deeper nesting raises manual cleanup cost. As a rule of thumb, shallow (2-3 levels) tends to convert with good accuracy; deep nesting realistically calls for visual verification in Figma plus some manual reorganization.

Q: How are XD repeat grids handled?

A: Repeat grids are a separate concern from components. They convert into an Auto Layout + Component + Instances structure. See Converting Adobe XD Stacks and Repeat Grids to Figma Auto Layout for details.

Q: Is component conversion available on the Free plan?

A: No — component conversion is a Pro plan (one-time $29, no subscription) feature. The Free plan covers shape / text / style / group / mask / image / transform. A common pattern is to verify structure conversion on Free first, then upgrade to Pro when you need component / Variants / instance resizing.

Q: Are overrides on instances (colors, text) preserved?

A: Yes — overrides for text content / color / image / visibility are preserved into Figma via the selective deep merge. Overrides that involve structural change (adding / removing / re-typing nodes) can’t carry into a Figma INSTANCE, so those instances are converted as plain Frames.

✅ Wrapping up

A summary of what to keep in mind when migrating XD components to Figma Components.

Key takeaways

1. The conceptual differences between XD and Figma components (structural flexibility on instances / how states are handled / override granularity)
2. The automatic mapping: Master → COMPONENT, States → Variants (State=<name>), overrides via selective merge
3. Four cases that need manual fixes (nesting / overrides with structural change / ambiguous state axes / very large components)
4. Five best practices for a smooth migration (naming / state naming / minimal nesting / pre-decomposition / Document Assets cleanup)

To use XD symbols as Figma Variants effectively, the realistic approach is a three-phase workflow: prep work in XD → automatic mapping during conversion → manual touch-ups in Figma. Teams operating core design systems tend to find that most of their migration cost concentrates around components, which is why “knowing how much automatic conversion will handle” is the key input for estimating migration project effort.

Related pages

• Features: Components conversion — formal spec, full parameters, and implementation notes
• Guide: Components — complete reference for conversion options (Eligibility / Quality / Scope)
• Converting Adobe XD Stacks and Repeat Grids to Figma Auto Layout — the Auto Layout axis (distinct from components)
• XD → Figma Migration: A Practical Guide — the full migration process
• XD → Figma Converter Plugins: An In-Depth Comparison — Pixel Fine Converter vs Angel Converter