The SVG path shown is broken, showing slightly why this would be a dodgy approach to apply here. Shown are these: <path d="M 1 1 L 1 -1 Z" /> <path d="m 1

The SVG path shown is broken, showing slightly why this would be a dodgy approach to apply here. Shown are these: <path d="M 1 1 L 1 -1 Z" /> <path d="m 1 1 L 2 0 z" /> But these are inconsistent. These show what I think was intended (a line from (1,1) to (2,0)): <path d="M 1 1 L 2 0 Z" /> <path d="m 1 1 l 1 -1 z" /> When you look at realistic illustrations, “lowercase everything” is fairly obviously not a good approach in path data: sometimes absolute coordinates will be shorter, other times relative coordinates will be shorter; and the difference, raw or compressed, will normally be more than the case difference. No, if you’re trying to compress, you should be taking the holistic approach, adjusting not just case, but the entire path data. For example, one of these two solutions, dropping the superfluous whitespace and removing the line-to opcode which is implied after an opening move-to: <path d="M1 1 2 0z"/> <path d="m1 1 1-1z"/> You can also contemplate whether you actually want to close the path. In this trivial case, it’ll only make a difference if you have exactly one of stroke-linejoin and stroke-linecap set to round.