Pixelquil logoPixelquil

Stroke to Fill Path Converter

Convert a stroked line into an equivalent filled shape for reliable scaling.

Original (stroke)
Converted (fill)
Click Convert to see the result

Converted SVG markup

Everything runs in your browser. Nothing you paste is uploaded or stored. This is an approximation using dense polyline sampling, not exact analytic curve offsetting.

How it works

  1. 1

    Paste or upload your SVG

    Paste SVG code containing one or more stroked shapes, or click Upload SVG to load a file from your device.

  2. 2

    Choose a cap style

    Round matches a rounded stroke end, Butt produces a flat, straight cut, matching how open paths should end.

  3. 3

    Click Convert

    Every stroked path, line, polyline, polygon, rect, circle, and ellipse in the SVG is converted into an equivalent filled outline.

  4. 4

    Review the result

    The preview shows the converted shape, which should look visually identical to the original stroke at normal sizes.

  5. 5

    Copy or download the converted SVG

    Use Copy or Download to get the final SVG with fill-based outlines instead of live strokes.

About the Stroke to Fill Path Converter

A stroked line's visible width is not part of the shape's geometry, it is a rendering instruction layered on top of a path, and that distinction causes real problems in certain contexts: a non-uniform CSS transform can stretch a stroke's width unevenly, some export pipelines and font-embedding tools do not preserve stroke properties at all, and stroke rendering can behave inconsistently across different SVG engines. Converting a stroke into an equivalent filled shape, expanding the stroke outline into actual solid geometry, sidesteps every one of these problems by representing the same visible line as pure, unambiguous fill area instead.

Why a stroke's width can distort unpredictably

A stroke's rendered width is calculated at render time, based on the path's centerline plus the current stroke-width value, which means it responds to transforms differently than the underlying path geometry does. A non-uniform scale transform, stretching an SVG's width by 150% while leaving its height unchanged, will distort the stroke's width unevenly along the path, thicker in some directions than others, even though the path's actual shape simply scales as expected. A filled shape has no such ambiguity, its geometry is exactly what it is, defined directly by fixed coordinates rather than recalculated at render time from a separate stroke-width value.

How this tool actually builds the filled outline

There is no closed-form mathematical formula for offsetting a curved path exactly, the standard practical approach, and the one this tool uses, is to flatten the path into a dense series of straight line segments using the browser's own native path-sampling methods, then calculate a parallel offset line on each side of that dense polyline at half the stroke width, and stitch the two offset lines together into one closed, filled shape. Because the sampling is dense, typically well over a hundred points along a normal-sized icon path, the resulting filled shape is visually indistinguishable from a true stroke at typical viewing sizes, even though it is technically built from many short straight segments rather than smooth mathematical curves.

What gets handled, and an honest note on precision

This tool processes path, line, polyline, polygon, rect, circle, and ellipse elements that have a stroke set, converting each into an equivalent filled outline while preserving any existing fill on the original shape underneath. Round and butt line caps are both supported, matching the endpoints of an open path with either a semicircular cap or a flat, straight cut. Being transparent about the limits: this is an approximation, not an exact analytic offset curve, sharp corners are smoothed slightly by the join-averaging technique used rather than rendered as a perfectly crisp analytic miter join, and square caps are not currently supported. For the overwhelming majority of icons and logos, this difference is not visible at normal viewing sizes, but it is worth knowing about if you are working with extremely large stroke widths relative to the artwork's size.

Real situations this solves

Converting stroke to fill matters most when an icon set needs to be embedded into a font, since icon fonts represent every glyph as filled outlines and have no concept of a stroke property at all. It also matters for certain animation libraries and CSS transform-heavy layouts where a non-uniform scale is applied to an icon, and for exporting artwork into contexts, like some game engines or design tools, that only reliably support filled path geometry rather than live stroke rendering.

Runs entirely in your browser

The flattening, offsetting, and outline construction all happen client side using your browser's own SVG geometry methods, nothing you paste is sent to a server. After converting, our SVG Optimizer is worth running afterward, since dense polyline-based outlines can produce a larger path data string than the original stroke, and cleanup helps bring that back down, part of the same SVG & Design Tools collection this tool belongs to.

Frequently asked questions

Why would I need to convert a stroke to a fill?

Filled shapes scale more predictably than strokes in some rendering and animation contexts, where stroke width can behave inconsistently across non-uniform transformations, and some export pipelines like icon fonts don't support strokes at all.

Does this change how the icon looks visually?

The goal is a visually near-identical result at typical viewing sizes, represented as fill geometry instead of a stroked line, though it is an approximation rather than a pixel-perfect analytic conversion.

Why is this described as an approximation rather than an exact conversion?

There is no closed-form mathematical formula for offsetting a curved path exactly. This tool uses the standard practical approach of flattening the path into a dense polyline first, then offsetting that, which is visually accurate at normal sizes but technically not a perfect analytic curve.

Are sharp corners preserved exactly?

Corners are smoothed slightly by the join-averaging technique used to compute offsets, rather than rendered as a perfectly crisp analytic miter join. This is not usually visible at normal icon sizes.

Which SVG elements does this tool support?

path, line, polyline, polygon, rect, circle, and ellipse elements with a stroke set are all converted. Elements without a stroke, or with stroke set to none, are left unchanged.

Does this support square line caps?

Currently only round and butt caps are supported. Square caps are not yet available and would need manual adjustment afterward if required.

Will the converted file be larger than the original?

Often yes, since a dense polyline-based outline typically needs more path data than a simple stroked line did. Running the result through our SVG Optimizer afterward helps bring the file size back down.

Is my SVG uploaded to a server?

No, all flattening and offset calculation happen entirely in your browser using native SVG geometry methods. Nothing you paste or upload is sent anywhere.