SVG Stroke to Fill Converter

How Vector Stroke to Fill Conversion Works

In vector graphics engineering, visual paths exist in two fundamentally distinct topological forms: 1-dimensional parametric open manifolds styled with line properties (strokes), and 2-dimensional closed planar boundaries enclosing an interior surface area (fills). While stroked paths provide lightweight mathematical representations for drawing lines, waves, and icon skeletons, they present notable limitations in responsive user interfaces, boolean graphic operations, font compilation, and computer-aided manufacturing (CAM). This SVG Stroke to Fill Converter algorithmically expands 1-dimensional stroked trajectories into closed 2-dimensional boundary ribbons using differential normal vector projection and hardware-accelerated sub-pixel curve sampling.

Differential Geometry: Normal Vector Offsets and Tangent Computation

Converting a stroked path of width \(w\) into an outlined filled shape requires computing parallel offset curves equidistant from the central trajectory. Consider a parametric vector curve defined as \(C(t) = (x(t), y(t))\) parameterized by normalized arc length \(t \in [0, 1]\). At any point along the curve, the velocity vector or first derivative defines the tangent direction:

T(t) = C'(t) = (dx/dt, dy/dt)

Normalizing this tangent vector yields the unit tangent vector \(\hat{T}(t) = T(t) / \|T(t)\|\). Rotating this unit tangent counter-clockwise by 90 degrees produces the perpendicular unit normal vector \(\hat{N}(t)\):

\hat{N}(t) = (-\hat{T}_y(t), \hat{T}_x(t))

The theoretical outer and inner offset boundaries are defined by displacing points along the normal direction by half the stroke width \(w / 2\):

C_{\text{outer}}(t) = C(t) + (w / 2) × \hat{N}(t)
C_{\text{inner}}(t) = C(t) - (w / 2) × \hat{N}(t)

In pure algebraic geometry, constructing exact symbolic offset equations for high-degree polynomial curves (such as cubic Bezier splines or elliptical arcs) is notoriously difficult. The offset of a cubic Bezier curve is generally a non-rational algebraic curve of degree 10, meaning it cannot be represented cleanly as another standard cubic Bezier. Attempting to approximate it with symbolic polynomial solvers in JavaScript causes severe performance degradation, numerical instability, and erratic ballooning artifacts around inflection points.

Browser-Native Hardware Curve Resolution via SVG DOM APIs

To eliminate heavy external geometric libraries while delivering real-time, sub-pixel accuracy across any arbitrary SVG command syntax (lines, cubic splines, quadratic beziers, and elliptical arcs), this converter uses the browser native graphics subsystem. The engine instantiates an off-screen SVG path element and queries standard W3C geometry methods:

• Total Arc Length Resolution: Calling tempPath.getTotalLength() computes the exact integral curve length across all constituent segments and elliptical projections.
• Parametric Coordinate Sampling: Calling tempPath.getPointAtLength(distance) returns precise Cartesian coordinates \((x, y)\) corresponding to any fractional distance along the trajectory.
• Central Finite Difference Tangents: To compute the local normal vector at point \(s\), the algorithm samples two adjacent points at small step intervals: \(P_{\text{pre}} = \text{getPointAtLength}(s - \Delta s)\) and \(P_{\text{post}} = \text{getPointAtLength}(s + \Delta s)\). The vector difference \((P_{\text{post}} - P_{\text{pre}})\) yields an exceptionally accurate numerical tangent, which is normalized and rotated 90 degrees to project the outer and inner ribbon boundaries.

Ribbon Topology and Directional Contour Stitching

Constructing a valid filled shape requires organizing offset coordinates into a single, non-self-intersecting continuous polygon. A naive algorithm might connect outer and inner points in parallel (e.g., from outer 0 to outer \(N\), then jumping back to inner 0 to inner \(N\)). That naive approach creates a diagonal crossing line across the center of the shape, creating visual clipping anomalies and invalid winding topology.

This tool employs closed ribbon traversal:

1. Forward Outer Contour (0 to N): The generator iterates from the start of the path to the end, emitting coordinates for the outer offset boundary \(C_{\text{outer}}\).
2. End Cap Transition: Upon reaching the final vertex \(N\), the path connects smoothly across the stroke thickness from \(C_{\text{outer}}(N)\) to \(C_{\text{inner}}(N)\).
3. Reverse Inner Contour (N down to 0): The generator traverses the inner boundary backward, moving from the end vertex back toward the origin.
4. Starting Cap Closure: The final inner point connects back to \(C_{\text{outer}}(0)\) and emits the SVG closepath command Z.

This closed loop ensures that the perimeter runs clockwise along the outer boundary and counter-clockwise along the inner boundary, forming an airtight manifold that renders uniformly across all graphics renderers.

Winding Rules: Non-Zero vs. Even-Odd Fill Algorithms

When stroked vector paths cross over themselves (such as spirals, infinity symbols, loops, or complex decorative flourish calligraphy), the resulting expanded ribbon creates overlapping geometric regions. The visual rendering of these intersections is determined by the SVG fill-rule property:

• Non-Zero (fill-rule="nonzero", Default): The browser casts an imaginary ray from any screen pixel to infinity, counting how many times path segments cross the ray from left to right (+1) versus right to left (-1). If the net sum is non-zero, the pixel is filled. In self-overlapping ribbons generated by this tool, overlapping areas retain a positive winding number and remain solidly filled, matching the visual appearance of thick intersecting brushstrokes.
• Even-Odd (fill-rule="evenodd"): The browser counts the total number of path boundary crossings without regard to direction. An odd count fills the pixel, while an even count leaves a hollow hole. Applying even-odd to self-intersecting ribbons creates cutouts at intersection points, which can be leveraged for stylized stencil effects.

Comparison: Stroked Paths vs. Outlined Fills

Understanding when to maintain center-line strokes versus converting to filled vector shapes is an essential architectural decision in modern software interface design:

Evaluation Criterion	Stroked Vector Path	Converted Filled Shape (This Tool)
Coordinate Payload Size	Small (Only centerline vertices)	Moderate (Dual outer/inner perimeter loops)
Responsive Uniform Scaling	Requires vector-effect: non-scaling-stroke	Inherently consistent at any scale
Boolean Shape Merging	Unsupported (Cannot union with solid fills)	Fully supported (Unions, subtractions, masks)
Icon Font Compilation	Fails (TTF/WOFF require closed glyph outlines)	Directly compatible with font forge pipelines
CNC & Laser Cutter CAM	Interpreted as single-pass score line	Interpreted as outer boundary cut path
Animation Flexibility	Supports stroke-dasharray draw-in effects	Supports area morphing and mesh deformation

Three Primary Engineering Use Cases

Expanding vector strokes into filled outlines solves concrete workflow bottlenecks across design and fabrication domains:

1. Standardizing Enterprise Icon Systems: Icon libraries (such as Lucide, Feather, and Heroicons) are initially drawn with consistent 2px center-line strokes. However, when icons are embedded into third-party component libraries or resized with CSS transform: scale(...), strokes can distort or appear disproportionately heavy. Converting icons into unified filled paths locks their visual weight and eliminates stylesheet inheritance bugs.
2. Digital Fabrication (CNC Milling, Plotters, and Lasers): Computer-Aided Manufacturing (CAM) tools for vinyl cutters (Cricut, Roland) and laser cutters (Glowforge, Epilog) interpret vector lines as cutting toolpaths. An open stroked path causes the laser or blade to trace down the middle of the stroke rather than cutting out the full shape. Converting the stroke to a filled polygon generates the exact dual-contour cut boundary needed to extract physical parts.
3. Icon Font and Glyph Generation: Vector font specifications (TrueType, OpenType, WOFF2) require every glyph to be a closed, filled Bezier contour. Open stroked paths cannot be rendered by font rasterizers. Converting stroked sketches into filled outlines allows designers to compile custom web font icons directly using tools like Fontello or IcoMoon.

Zero-Server Browser Processing and Privacy

All path length evaluations, trigonometric normal projections, and SVG string generation execute 100% within your client browser memory using standard ECMAScript and W3C SVG APIs. Zero coordinates, design assets, or proprietary icon vectors are ever transmitted across external networks or stored on remote servers.