CSS Clip-Path Maker Output Quality and the Hand-Written Replacement

You paste a link into a clip-path maker, slide the handles until the polygon looks right, copy the CSS, and ship it. The output works in your browser because your browser is Chromium-based and tolerates the stale WebKit prefix. But the same CSS clip-path maker output breaks in Firefox and Safari on the next resize, and the accessibility tree loses the content entirely. The fix is not a better tool. It is knowing what the generator emits and writing the replacement yourself, by hand.

Open any free clip-path tool and the textarea below the preview shows something like this:

```css
.element {
  -webkit-clip-path: polygon(50% 0%, 100% 50%, 50% 100%, 0% 50%);
  clip-path: polygon(50% 0%, 100% 50%, 50% 100%, 0% 50%);
}
```

The unprefixed line is fine. The prefixed line is dead weight. Blink, WebKit, and Gecko all shipped unprefixed clip-path years ago. The -webkit- prefix adds bytes and confuses anyone reading the code later. More important, the tool often uses absolute pixel coordinates when you drag handles on a fixed canvas. That output clips the element relative to its own border-box. If the element resizes or the viewport changes, the shape crops the wrong area or leaves gaps. The tool has no way to know your layout is fluid, and it does not ask.

A clip-path generator review usually praises the drag-and-drop interface and the live preview. Those are real conveniences for prototyping. The wrong assumption is that the output is production-ready. The tool cannot know your fallback strategy, your responsive breakpoints, or your accessibility requirements. It emits a single declaration block with no @supports query, no unclipped base style, and no percentage-based reasoning about the element's own dimensions. Use the tool to sketch the shape, then note the coordinates and hand-write the CSS. The tool is a sketchpad, not a compiler.

Use Percentages, Not Pixels

When you write the clip-path yourself, use percentages for polygon, circle, ellipse, and inset values. Percentages resolve against the element's own border-box, not the viewport. That is the single most common mistake: using viewport-relative thinking on a property that is element-relative. For a card that should be a diamond at any width, the hand-written version is:

```css
.card {
  clip-path: polygon(50% 0%, 100% 50%, 50% 100%, 0% 50%);
}
```

That works at any size because the coordinates are relative to the card itself. If you need a shape that adapts to the viewport, use container queries or aspect-ratio to control the element, not absolute pixel values in the clip.

SVG Elements and the Reference Box

For SVG elements in HTML, the reference box defaults to fill-box. Percentages resolve against the SVG's bounding box. Firefox requires applying clip-path via CSS, not the deprecated presentation attribute. Keep the geometry simple: polygon with a handful of points, circle with a radius and position, ellipse with two radii. Avoid path() unless you are comfortable with SVG path data. Path coordinates are absolute and do not scale with the element.

Paint and Layout

Clip-path is neither free nor devastating. The paint cost is medium: the browser rasterises the clipped region, and for large elements with complex paths that is real work. The layout cost is none. Clip-path does not affect the box's dimensions or the position of siblings.

Animation and Hit-Testing

The compositor eligibility is partial. A static clip-path is applied at paint time, but animating it forces a repaint on the main thread. If you want to animate a clip, animate a transform or opacity instead, and keep the clip static. The Cumulative Layout Shift contribution is zero, because clip-path reserves no space and moves no layout. The real cost is on interaction: a clipped element still has its original hit-testing area unless you account for it. Clicks land in invisible space. That is a usability bug, not a performance one.

Clip-path does not remove content from the accessibility tree by itself. The image or text remains exposed to assistive technology, which is good for screen readers. The failure appears when you pair clip-path with a fallback that hides the element, or when you use it on a link or button and the visible shape is smaller than the hit area.

The accessible pattern: provide an unclipped base style, then the clip as a progressive enhancement. The base style shows the full element. The clip trims it visually. If an older browser does not support clip-path, the user sees the full element, which is still functional. Do not use display: none as a fallback. It removes everything from the accessibility tree. A polygon that cuts off the text label of a button leaves a visible shape with no readable name. Keep the content inside the clip area, or provide an aria-label on the clipped element.

The accepted fallback pattern is a base style without clip-path, then an @supports query that adds it. The query tests a property:value pair the browser can parse. For clip-path, test the simplest shape:

```css
.shape {
  background: #f5f5f5;
  padding: 2rem;
}

@supports (clip-path: circle(0)) {
  .shape {
    clip-path: polygon(50% 0%, 100% 100%, 0% 100%);
    background: #d32f2f;
  }
}
```

This hides the clip in browsers that do not support it, but the element still renders as a rectangle with its padding and background. The content stays readable and the layout does not shift. Without the @supports wrapper, an unsupported browser ignores the clip-path declaration entirely and shows the border-box. That is fine if your design does not depend on the clip. But if the clip is essential to the visual design, the base style is what the user gets. Do not rely on the clip for critical visual information like a status colour. The fallback rectangle must be acceptable.

The first failure is the stale prefix. The generator writes -webkit-clip-path, which modern Blink, WebKit, and Gecko all ignore. The unprefixed property has been widely available since mid-2017, a Baseline status that means every current engine supports it. The prefix is harmless but misleading; it signals the code is old.

The second failure is absolute units. A generator that outputs pixels for a polygon coordinate set is unusable in a responsive layout. Replace the pixel values with percentages, which resolve against the element's border-box.

The third failure is the missing fallback. A bare clip-path declaration in a browser that lacks support silently renders the full box, which breaks the visual design. The @supports pattern above is the standard answer.

Does clip-path work on all browsers in 2026?

Yes, for the basic shapes polygon, circle, ellipse, and inset. Baseline status marks it widely available since 2017. The edge cases are url() references to SVG clipPath, which animate poorly, and path() which has spotty support in older engines. Stick to basic shapes with percentages and you are safe.

What is the difference between -webkit-clip-path and clip-path?

The prefixed version was needed before 2016. Modern engines dropped the prefix. Write only the unprefixed declaration. If you copy code from an old generator, delete the -webkit- line.

Can I animate clip-path?

Technically yes, but the animation runs on the main thread and triggers paint on every frame. That is a medium paint cost for a simple shape and high for a complex path. Animate transform or opacity instead and keep the clip static.

How do I calculate percentage coordinates for a polygon?

Percentages are relative to the element's own border-box. A point at 50% 0% is the top center, 100% 100% is the bottom right. The generator's pixel values can be converted only if you know the element's size. For a fluid layout, rewrite them as percentages manually.

Does clip-path affect click targets?

Yes. The hit-testing area is the original border-box, not the clipped shape. If a button is clipped to a triangle, clicks in the now-invisible corners still count. Use pointer-events on the clipped area or enlarge the shape.

Is clip-path the same as border-radius?

No. Border-radius rounds corners and does not clip content. Clip-path cuts the element's rendering entirely. Text or images outside the shape are not drawn. Use border-radius for simple rounded rectangles and clip-path for arbitrary shapes.

What is the difference between clip-path and overflow: hidden?

Overflow hidden clips to the padding box and removes content from the accessibility tree if the content is scrolled away. Clip-path clips to an arbitrary shape and keeps the content in the accessibility tree. Use overflow for rectangular clipping and clip-path for shapes.

Here is the full pattern for a card with a parallelogram clip, using percentages and an @supports fallback. The base style is a plain rectangle. The supported-browser style adds the clip and a distinct background. The unsupported browser shows the rectangle with padding, which is acceptable.

```css
.card {
  padding: 2rem 3rem;
  background: #e0e0e0;
  color: #212121;
}

@supports (clip-path: polygon(0 0, 100% 0, 85% 100%, 0 100%)) {
  .card {
    clip-path: polygon(0 0, 100% 0, 85% 100%, 0 100%);
    background: #1565c0;
    color: white;
  }
}
```

Notice the coordinates are percentages, so the card scales with its container. The fallback keeps the content visible and the layout intact. If you need the clip only on wide screens, wrap the @supports in a media query. If you need the clip to be the entire element, set the padding to zero and let the clip define the shape.

Skip the generator entirely for three cases. First, when you need a circle or ellipse: hand-writing circle(50% at 50% 50%) is faster than dragging a handle. Second, when you need an inset with rounded corners: inset(20px 10px round 15px) is a single line. Third, when you need an SVG clipPath with url(#id): the generator cannot produce that reliably, and the SVG reference box behaves differently across engines. For any polygon with more than eight points, the generator is useful for the geometry, but you still have to convert the coordinates to percentages and add the fallback. The tool is not worth the detour when your shape is simple.

Clip-path is a Baseline widely available feature. Every current browser supports it. The practical gap is older device-locked browsers, like iOS Safari on unsupported iPhones or Android WebView in apps that do not update. That population is small but real, and the @supports fallback covers it. Do not trust a caniuse percentage that claims 100% support; the real gap is users on those older engines, a slice that no survey measures reliably. The fallback is cheap, so use it. For SVG clipPath references, Firefox requires the clip-path property applied via CSS, not the presentation attribute. The url() form does not animate. If you need animation, use a basic shape instead.

Clip-path changes what the user sees but not how the document flows. It never affects the size, position, or reading order of other elements. That is its strength and its trap. You can create a visually striking shape without breaking the grid. You cannot use it to reposition content. If you need a layout that reflows, use flexbox or grid. If you need a visual mask, clip-path is the right tool. The hand-written version with percentages and an @supports fallback is the only reliable way to ship it.