Stop Guessing Conic Gradient Syntax: Cheat Sheet

Set your first color stop at 0deg and your last at 360deg — every time

That single habit eliminates roughly 80% of the broken conic gradients I see in code reviews. When you omit explicit positions, the browser silently distributes stops across the full circle, which sounds helpful until you add a fourth or fifth color and the distribution shifts on you. Pin the endpoints. Everything in between becomes predictable.

Now, let's slow down and build the mental model properly. The reason so many developers struggle with conic-gradient() isn't laziness — it's that the syntax looks deceptively similar to linear-gradient() while behaving under completely different geometric rules. You're not painting a line. You're painting a circle, one sweep at a time, starting from a specific angle and rotating clockwise by default. If you've ever stared at a pie chart that looked like a cracked windshield, the angle model is usually where things went sideways.

The full anatomy, broken down piece by piece

Here is the complete syntax skeleton, stripped to its essentials:

conic-gradient([from <angle>] [at <position>], <color-stop>, <color-stop>, ...)

Three moving parts. Let's walk through each one the way I'd explain it to a junior dev sitting next to me.

The "from" angle — where the sweep begins

By default, the gradient starts at the top of the element, which is 0deg in conic space. This is different from CSS transform angles, where 0deg points to the right. That mismatch trips people up constantly. If you want the sweep to start from the right edge — matching what your brain expects from a standard Cartesian plane — you write from 90deg.

A practical example: if you're building a loading spinner that should "begin" visually at the 12 o'clock position, omit the from keyword entirely. The default has you covered. But if your design spec says the spinner arc should originate from 3 o'clock, add from 90deg. One keyword, one number, no guessing.

The "at" position — the center of rotation

This controls where the pivot point sits within the element. The default is at center, or equivalently at 50% 50%. You can offset it: at 30% 70% pushes the rotation center toward the bottom-left, which creates an asymmetric sweep that can look striking behind a hero section.

The key insight: the "at" position does not change where colors appear in the rotation. It changes the visual focal point. Colors still progress through the same angular sequence — they just orbit around a different anchor.

Color stops — the actual paint

Each stop has a color and an optional position. Positions can be in degrees (deg), turns (turn), percentages (%), or even gradians (grad) if you enjoy confusing your teammates. I recommend degrees for everything. Turns are compact (0.5turn = 180deg) but they make mid-gradient math harder when you're debugging.

Hard stops: the technique that makes pie charts work

Here's where the cheat sheet earns its keep. A hard stop — two colors at the same position — creates a clean boundary with zero blur. This is how you build pie charts, color wheels, and segmented rings without reaching for SVG.

The pattern:

conic-gradient(#e63946 0deg 90deg, #f1faee 90deg 180deg, #a8dadc 180deg 270deg, #457b9d 270deg 360deg)

Notice the shorthand: #e63946 0deg 90deg means "red from 0 to 90 degrees." No comma between the two positions on the same color. The comma separates stops, not positions. Get that wrong and the browser ignores the declaration silently — no error, no warning, just a blank or default-colored box.

That silent failure is the single most common pain point I see in dev tools sessions. You inspect the element, the computed styles panel shows your gradient string intact, but the element renders nothing. Nine times out of ten, a misplaced comma or a missing unit is the culprit. The browser doesn't throw — it just discards the invalid value and falls back.

Smooth transitions: letting the browser interpolate

When you want a soft blend between colors, simply leave a gap between positions:

conic-gradient(#264653 0deg, #2a9d8f 120deg, #e9c46a 240deg, #264653 360deg)

Here, the browser fills the space between each stop with a smooth interpolation. No hard edges. The transition between #2a9d8f at 120deg and #e9c46a at 240deg spans 120 degrees of arc — a wide, gradual shift.

A useful calculation: if you have four colors and want equal smooth bands, divide 360 by 4. Each band gets 90 degrees. Place stops at 0, 90, 180, 270, and 360. That math — 360 divided by your stop count — is the backbone of every evenly distributed conic gradient you'll ever write.

Repeating conic gradients: the pattern multiplier

Standard conic-gradient() fills the full circle and stops. If you want a repeating pattern — think radar sweeps, sunburst loaders, or textured backgrounds — use repeating-conic-gradient() instead. The syntax is identical, but the browser tiles your stop sequence around the full 360 degrees.

Example:

repeating-conic-gradient(#1d3557 0deg 10deg, #e63946 10deg 20deg)

This creates 18 alternating wedges (360 ÷ 20 = 18 segments). Each wedge is 10 degrees wide. Change the 20deg to 30deg and you get 12 wedges. The math is immediate and testable in your browser's dev tools — no build step required.

Debugging in browser dev tools: the workflow that saves hours

Open Chrome or Firefox DevTools, inspect the element with your gradient, and click the small swatch icon next to the background declaration. A visual editor appears. You can drag color stops around the circle in real time. This is not a gimmick — it is the fastest way to internalize how angle positions map to visual output.

Here's the workflow I teach every developer I mentor:

First, write your gradient with explicit degree positions on every stop. Second, open the visual editor and drag stops until the gradient looks right. Third, read back the final values from the editor and paste them into your stylesheet. You're using the browser as a WYSIWYG editor for CSS. No trial-and-error refresh cycles.

One caveat: the visual editor in Chrome DevTools rounds to integers. If you need sub-degree precision (rare, but it happens in animation work), you'll need to hand-tune the values in the source panel afterward.

The five mistakes I see in every codebase

After reviewing hundreds of gradient declarations, these are the recurring failures:

1. Mixing units. Writing conic-gradient(red 0deg, blue 50%, green 1turn) is valid but unreadable when you return to it three months later. Pick degrees and stick with them across the entire declaration.

2. Forgetting the closing 360deg stop. Without it, the last color stretches to fill remaining space. Sometimes that's what you want. Often it isn't. Be intentional.

3. Using percentages when you mean degrees. 50% in a conic gradient equals 180deg, not "halfway across the element." The percentage refers to angular position, not spatial width. This is the #1 source of confusion for developers coming from linear gradients.

4. Omitting the "from" keyword when it matters. If your design system specifies a consistent starting angle for all spinners and rings, encode it. Don't rely on the default and hope nobody notices.

5. Not testing in a square container. Conic gradients are circular, but they fill rectangular elements. The corners of a wide rectangle will show the gradient's edge colors stretched outward. Always preview in the actual aspect ratio you're shipping.

Putting it all together: a copy-paste reference

Here's a compact reference you can keep in your snippets library:

/* Pie chart — 4 equal hard segments */
background: conic-gradient(#e63946 0deg 90deg, #f1faee 90deg 180deg, #a8dadc 180deg 270deg, #457b9d 270deg 360deg);

/* Smooth color wheel */
background: conic-gradient(red, yellow, lime, cyan, blue, magenta, red);

/* Offset center, custom start angle */
background: conic-gradient(from 45deg at 30% 70%, #264653, #2a9d8f, #e9c46a, #264653);

/* Repeating radar sweep — 12 wedges */
background: repeating-conic-gradient(#1d3557 0deg 15deg, transparent 15deg 30deg);

Keep these four patterns in your back pocket and you'll cover the vast majority of conic gradient use cases in production CSS. The syntax is compact, the browser support is universal across modern browsers, and the visual payoff — once you internalize the angle model — is immediate.