How XD Colors and Gradients Translate to Figma — A Practical Look at the 4 Gradient Types and Angle Correction

When designers move from Adobe XD to Figma, the most common report about color is reassuring: “the colors came over fine.” The more nuanced one is about gradients: “they look slightly off — the angle is different, or the highlight shifted.” Both are correct, and the reason has more to do with how the two tools represent gradients internally than with any single conversion bug.

This article walks through how XD colors and gradients translate to Figma, based on what Pixel Fine Converter actually does at runtime. We’ll cover solid fills, the four gradient types, stops and transform matrices, and the angle correction that lives behind the Pro tier.

📝 Introduction — Colors carry over cleanly, gradients depend on the type

XD and Figma are both vector-based design tools, so solid color values are relatively easy to carry over. Gradients are where the differences in internal representation surface.

XD ships with Linear, Radial, and Angular gradients as its standard offering. Figma supports those three plus Diamond, for a total of four gradient types. The mapping between them is mostly aligned, but the angle, center position, and aspect handling can diverge depending on the shape of the element you’re applying the gradient to.

Here are the five angles we’ll cover:

1. Solid fills and strokes — how faithfully colors carry over
2. Color assets (XD’s named color variables) — whether they become Figma Color Styles
3. Gradient types — the Linear / Radial / Angular / Diamond mapping
4. Gradient stops (the positions where colors switch within a gradient) and transform matrices — the underlying representation
5. Non-square angle correction — the Pro feature that bridges XD’s and Figma’s handling

🎨 Color transfer — Solid fills, strokes, and color assets

Solid fills — effectively lossless

A solid fill or stroke in XD carries over to Figma with the color value (RGB plus alpha) intact. On the Figma side, the fill type is SOLID, and a #FF6B35 in XD ends up as the same #FF6B35 in Figma.

Opacity is preserved as a separate attribute, so any “color plus transparency” combination you’ve set in XD reappears as the same layer setup in Figma.

Strokes

Strokes carry the same color and opacity treatment as fills. Stroke width, cap and join settings, and dash patterns are tracked separately and are outside this article’s scope, but the color fidelity itself is on par with fills.

Color assets — preserved as Figma Color Styles?

XD has a “Color Asset” concept — named colors like primary-blue that multiple layers reference. The migration question is whether those named references survive as Figma Color Styles, or whether they get flattened into raw color values on every layer.

Pixel Fine Converter only registers XD Color Assets as Figma Paint Styles (Color Styles) when Pro’s “Register as Local Styles” option is enabled. On Free, or with the option disabled, color assets are flattened into per-element fill values.

The practical difference matters: with Pro and the option on, you can change a value once and update every layer that uses it. Otherwise you have to rebuild the Color Style system in Figma after migration. Note that gradient-based Color Assets are currently outside the Paint Style registration path and are always flattened to per-element fills regardless of tier.

🌈 The four gradient types — Linear, Radial, Angular, Diamond

Figma supports four gradient types, and Pixel Fine Converter handles all four in its conversion path. XD’s authoring tools natively produce three of them (Linear, Radial, Angular), and Diamond is the one type unique to Figma.

Pixel Fine Converter processes all four types through the same code path, carrying over the gradient stops (color + position) and the transform matrix (angle, position, scale). A Linear, Radial, or Angular gradient authored in XD comes through as the same type on the Figma side.

📐 Gradient stops and the transform matrix

A gradient is defined by two things: which colors sit at which positions (the stops) and the direction and scale of the color flow (the transform matrix). Pixel Fine Converter reads both from XD and writes both to Figma.

Stops

Stops are stored as an array of { color, position }, with position normalized to the 0.0–1.0 range. If you put five stops in XD, Pixel Fine Converter carries the same five into Figma, with color values, positions, and alpha intact.

The stop order, color values, and transparency carry over losslessly — visual before/after comparisons show stop structure as identical.

Transform matrix

This is where things get more technical. Figma represents gradients with a 2×3 affine transform matrix (2 rows × 3 columns, six scalars: m00, m01, m02, m10, m11, m12) that encodes the angle, center position, and scale of how the color flow extends across the element.

Pixel Fine Converter builds this matrix from XD’s gradient data and writes it to Figma’s gradientTransform. Internally, XD and Figma represent gradient orientation differently, so Pixel Fine Converter is doing this translation behind the scenes.

🎯 Angle correction for non-square elements — what the Pro feature does

The biggest visible gap between XD’s and Figma’s gradient handling shows up on non-square elements — wide or tall rectangles, ellipses, and other shapes where the bounding box isn’t a square.

Why the angle drifts

The technical reason is straightforward: XD defines its gradient angle in a coordinate system that ignores aspect ratio, while Figma normalizes the angle against the element’s bounding box. A concrete example makes this easier to picture.

Take a “45-degree” linear gradient applied to a 400×100 wide rectangle. In XD, the angle is rendered with the aspect ratio baked in — the visual angle on screen is what you authored. Figma interprets the same 45 degrees against the bounding box’s normalized coordinate system, which is enough to make the same number look like a different angle in the rendered output.

A built-in option for angle correction

Pixel Fine Converter includes an option for this case — labeled Correct gradient angle for non-square elements in the UI — that recalculates the angle with the aspect ratio in mind, so the rendered output on the Figma side stays closer to what you saw in XD.

Typical before/after cases

• Square (200×200px) with a 45° linear gradient → Free and Pro look essentially the same
• Wide (400×100px) with a 45° linear gradient → Free renders a shallower angle; Pro stays closer to the XD original
• Tall (100×400px) with a 45° linear gradient → Free renders a steeper angle; Pro stays closer to the XD original

In real projects — hero buttons, card backgrounds, modal surfaces — non-square gradient elements are the rule, not the exception. The Pro angle correction is felt most strongly in pixel-accuracy-critical scenes.

📌 Edge cases that don’t translate cleanly

Color and gradient transfer is generally smooth, but a few edge cases benefit from extra attention.

1. Gradients applied to text

A gradient applied uniformly to a text layer in XD usually carries over. Per-character or per-line gradients (where different characters use different gradient values) tend to need re-authoring in Figma, since the underlying representation differs.

2. Multiple fills on a single layer

A single XD layer with stacked fills carries over to Figma as a multi-fill layer, but blend modes and opacity stacking can shift the final composite slightly. For important hero elements, a visual sanity check after migration is worth doing.

3. Off-center Radial gradient positions

If a radial gradient’s center is offset well away from the element’s geometric center, the coordinate-system translation can introduce a small positional drift. Spot-check highlight placement on critical visuals.

4. Gradients combined with blend modes

Gradients combined with blend modes (Multiply, Screen, Overlay, etc.) can land differently in Figma because of how each renderer evaluates the composite. This is less a Pixel Fine Converter issue and more a rendering-engine difference between XD and Figma.

5. XD Angular gradients (partial β coverage)

XD’s Angular gradient is currently in partial β coverage for Pixel Fine Converter — full support is planned in a future phase. For designs that lean heavily on Angular gradients, expect some manual re-authoring on the Figma side for now. Linear and Radial are fully supported, so it’s worth leading with those two types where possible.

⚖️ How Pixel Fine Converter compares to other plugins

XD-to-Figma converter plugins vary in how faithfully they handle colors and gradients.

• Pixel Fine Converter — Converts all four gradient types; Pro tier adds aspect-aware angle correction for non-square elements
• Other plugins — Linear and Radial coverage is broadly available, but stop precision and angle handling tend to be where differences emerge

For a full head-to-head, see XD→Figma conversion plugins compared.

❓ FAQ

Q1. Do solid colors from XD carry over to Figma exactly?

Yes. HEX values, alpha, and opacity transfer with full fidelity — the HEX you see in XD’s inspector is the HEX Figma shows after migration.

Q2. Do XD Color Assets become Figma Color Styles?

Only when Pixel Fine Converter Pro’s “Register as Local Styles” option is enabled — in that case, single-color XD Color Assets are registered as Figma Paint Styles. On Free, or with the option disabled, they’re flattened into per-element fill values. Gradient-based Color Assets are currently outside the Paint Style registration path regardless of tier and are always flattened.

Q3. My gradients look slightly off after migration — what’s going on?

The most common cause is non-square elements (wide or tall rectangles) with Linear or Radial gradients. The two tools interpret angles differently against the bounding box. Pixel Fine Converter Pro’s Correct gradient angle for non-square elements option compensates for this.

Q4. Can I author Diamond gradients in XD?

XD’s native UI doesn’t author Diamond gradients (XD’s standard offering is Linear, Radial, and Angular). If your XD design fakes a diamond look by stacking fills, rebuilding it as a native Diamond gradient in Figma is usually cleaner than trying to force the migration to preserve the stack.

Q5. Do gradients applied to text carry over?

A gradient applied uniformly to a text layer usually transfers. Per-character or per-line gradient assignments may need re-authoring in Figma.

Q6. Are gradient stops preserved accurately?

Yes — stop order, color values, positions, and alpha carry over losslessly.

🎯 Wrap-up

Color and gradient transfer from XD to Figma is largely smooth, with one notable area where internal-spec differences are visible: the rendered angle of gradients on non-square elements. That’s where Pixel Fine Converter Pro’s angle correction earns its keep.

• Solid fills and strokes: effectively lossless, HEX-level match
• Four gradient types: Pixel Fine Converter handles all of them, carrying stops and the transform matrix through
• Non-square elements: Pro’s angle correction keeps the Figma output close to the XD original
• Edge cases (text gradients, multiple fills, blend modes): worth a visual check after migration

If “the colors are fine but the gradients feel off” sounds familiar, the cause is almost always the non-square angle gap. For gradient-heavy projects, the Pro tier’s correction is worth a try.

Related articles

• Adobe XD to Figma migration — a practical guide — End-to-end migration process and common pitfalls
• Free XD to Figma conversion — when paid plugins are worth it — Where the free/paid line actually lands
• XD→Figma conversion plugins compared — Side-by-side accuracy review
• Opening XD files in Figma — a visual walkthrough for designers — Step-by-step plugin UI walkthrough
• Three ways to open Adobe XD files in Figma — Web service / plugin / manual export compared
• Adobe XD end-of-support — timeline and migration windows — When XD support actually ends and what it means