Intent to Ship: SVG Path Data API

[Chromestatus]

Contact emails

virali...@microsoft.com, ste...@microsoft.com

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/SVG/SVGPathDataAPI/explainer.md

Specification

https://w3c.github.io/svgwg/specs/paths/#InterfaceSVGPathData

Design docs

https://docs.google.com/document/d/1uCVUqYGKgsCCu7LEtEdO3Yuea-MT-I2XsU6Eoe3mlQI/edit?usp=sharing

Summary

Adds structured JavaScript access to SVG path data through three methods on SVGPathElement: getPathData() reads the path as an array of {type, values} objects containing each segment's command and numeric parameters. setPathData() updates the path from such an array, getPathSegmentAtLength() returns the segment at a specified distance along the path. These methods let developers inspect, edit, and construct paths without manually parsing or serializing the d attribute. The optional getPathData({normalize: true}) setting simplifies path data to absolute move, line, cubic Bézier, and close commands (M, L, C, and Z). All three APIs operate on the base value of the d attribute, not CSS-computed or animated values.

Blink component

Blink>SVG

Web Feature ID

No information provided

Motivation

In Chromium, inspecting or modifying individual SVG path segments requires parsing and serializing the d attribute string, often using third-party libraries. This makes tasks such as path animation, hit-testing, and programmatic path construction unnecessarily complex and error-prone. The previous SVGPathSegList API was removed in Chromium 48 because of its complex live mutation model, numerous factory methods, and underspecified edge cases. Developers have since relied on polyfills to restore structured access. Implementing the SVG Working Group’s replacement API provides a simpler, standardized way to read and modify path segments without custom string parsing or polyfills.

Initial public proposal

No information provided

TAG review

https://github.com/w3ctag/design-reviews/issues/1292

TAG review status

Pending

Goals for experimentation

Risks

Interoperability and Compatibility

Low risk. The feature adds new methods to SVGPathElement that developers can feature-detect before use. Representatives from Chromium, Firefox, WebKit, and the web developer community contributed to the API design through the SVG Working Group.

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1934525) Firefox 137 shipped the feature in April 2025.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/731)

Web developers: Positive (https://issues.chromium.org/issues/40441025) 45 users upvoted this Chromium issue. A widely used polyfill exists: https://github.com/jarek-foksa/path-data-polyfill

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None. The feature adds new methods to SVGPathElement that developers can feature-detect before use.

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/svg/path/interfaces?label=experimental&label=master&aligned

Flag name on about://flags

No information provided

Finch feature name

SVGPathDataAPI

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/40441025

Measurement

Use counters include: - SVGPathElementGetPathData - SVGPathElementSetPathData -SVGPathElementGetPathSegmentAtLength

Availability expectation

The feature is available in Chromium and Firefox for the foreseeable future. Microsoft proposed this feature as a focus area for Interop 2027: https://github.com/web-platform-tests/interop/issues/1469, which if accepted, could help extend support to additional browsers.

Adoption expectation

The feature replaces a popular polyfill that developers use today with thousands of downloads per week. The Chromium issue has 45 votes. Developers have made inquiries, asking when it will become available.

Adoption plan

MDN already documents this feature. Given the existing developer interest, the feature's adoption should grow organically.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

None.

Estimated milestones

Shipping on desktop	159
Shipping on Android	159
Shipping on WebView	159

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None. Representatives from Chromium, Firefox, WebKit, and the web developer community contributed to the API design through the W3C SVG WG.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4787972240179200?gate=4660848254648320

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/KUXP153MB161031AEB43220B1ADB9B41AC1112%40KUXP153MB1610.APCP153.PROD.OUTLOOK.COM

This intent message was generated by Chrome Platform Status.