Conic Gradients: Visual Editor vs Manual CSS Workflows

The visual editor exported me a gradient with no vendor prefixes and a flat color fallback. I nearly shipped both into a design system.

A visual conic gradient editor is a genuine upgrade over typing angles by hand. You drag, you see it live, you export. But "export" is doing more work than the button implies, and two of its defaults will surprise you if you do not read what it actually writes out. I read the generated code before pasting it into a component library, and I am glad I did.

Here is what a visual editor for conic gradients actually emits, what its fallback strategy really is, and the three places where the output is less complete than hand-written CSS would be.

What the editor writes when you hit export

The tool builds its output in two passes. First it constructs the gradient function value, then it wraps it in either a CSS block or a React style object. The gradient builder looks like this:

conic-gradient(from ' + angle + 'deg at ' +
  cx + '% ' + cy + '%, ' + colorStops + ')'

So an editor state with a 180 degree angle, a center at 50/50, and three stops becomes a single clean line: conic-gradient(from 180deg at 50% 50%, #ff6b6b 0%, #4ecdc4 50%, #ff6b6b 100%). That part is exactly what you want and faster to reach than typing it. The interesting decisions happen in the two wrapper functions.

The CSS export deliberately skips the vendor prefixes for conic

For linear and radial gradients, the CSS block writes a prefixed line before the standard one:

.gradient {
  background: #ff6b6b; /* fallback for old browsers */
  background: -webkit-linear-gradient(...);
  background: -moz-linear-gradient(...);
  background: linear-gradient(...);
}

But look at the guard around those prefix lines in the source. It only emits them when the gradient type is not conic. The comment explains the reasoning: there was never a prefixed -webkit-conic-gradient era the way there was for linear and radial, so the editor does not fabricate prefixes that never existed. That is a correct and defensible choice, and it means your conic export is shorter than your linear export for a real reason. Just know that if you were expecting symmetry with the linear output, you will not get it, and you should not add fake prefixes by hand.

The fallback is one flat color, and it is the first stop — not a blend

Every export carries a fallback line for browsers that cannot render the gradient at all. The editor computes it from the color stops, and the logic is one line:

// fallback is the first (lowest-position) color stop
function fallbackColor(st) {
  var sorted = normalizeStops(st.stops);
  return sorted.length ? normalizeHex(sorted[0].color) : '#FFFFFF';
}

So the fallback is the single color of whichever stop sorts first by position, and if there are no stops it is white. It is not an average of your gradient, not the midpoint color, and not your background color. For a gradient that runs red to teal, the fallback is solid red. If the first stop happens to be a color you would never pick as a brand surface, your legacy-browser users get that flat color full-bleed. Set the first stop deliberately, or accept the fallback the editor chose for you.

React export is the same gradient in camelCase, and nothing else changes

The React output is not a component, it is a style object, and it mirrors the CSS block one to one:

const gradientStyle = {
  background: '#ff6b6b', // fallback
  backgroundImage: 'conic-gradient(from 180deg at 50% 50%, ...)',
};

The one structural detail to notice is that the fallback and the gradient live on different keys. In CSS you stack two background declarations and the browser uses whichever it can parse. In a React style object there is no stacking, so a browser that cannot parse conic-gradient falls back to the background color, and a modern browser renders the backgroundImage on top of it. That is the intended behavior, and it is why the object keeps both keys. If you strip the fallback line to "clean up" the object, you remove the only thing old browsers can render.

Three things the editor does not do, that you still have to

1. It does not give you the CSS custom-property version. The export is a literal value with baked-in colors. If your design system themes gradients by variable, you rewrite the stop colors into var(--...) references yourself.
2. It does not generate the fallback you might want. The flat first-stop color is fine, but a soft page often wants a linear approximation as the middle ground. That is a hand addition.
3. It does not tell you where the angle origin is in your own layout. The from angle is measured from the top of the element, not the page. Rotate a card and your 180 degrees is no longer "bottom." Verify in your real container, not the editor preview.

Read the export before you paste it, every time

The value of a visual conic gradient editor is that it collapses 15 minutes of type-and-squint into 45 seconds of drag-and-drop. That is real. But the export button is a code generator with its own opinions, and the two that matter are the missing conic prefixes (intentional) and the single-first-stop fallback (easy to ship by accident).

Use the editor for the part it is brilliant at, the visual iteration, then spend 30 seconds reading the two wrapper lines it wrote for you. The gradient you dragged into shape is exactly right; the fallback and the prefix policy are the parts that deserve a second look.