[anecd0te]

What I've found working with geometric data like SVG is that your software will use some kind of internal representation that looks quite different than SVG, so you will do some kind of parsing into your data structure and then serializing out to SVG at the end. Even doing something like serialize(parse(number)) is not guaranteed to be lossless.

The only way to avoid doing that losslessly is to track the original text that you parsed into your IR nodes, which is a bit expensive if you think about it. A double is 64 bits, most shape/path data is packed and dense lists of doubles. Interleaving strings or ids that can be used to track them can be really annoying to thread through your program without performance or memory issues.

[TobTobXX]

Inkscape is close to that. An Inkscape save file is a valid SVG file, but some SVG processors don't display all things correctly, so it also allows you to export it as "Plain SVG". But most browsers would read an inkscape save file just fine.

(Note that if you want to serve the SVG file, you should still "export as SVG" it, since Inkscape embeds a lot of semi-sensitive informations into the SVG like file path etc.)