SVG export format completely changed with Illustrator 28.4

[Andy Swift]

[update August 2, 2024]

With Illustrator 28.6, Adobe again changed the SVG format. They seem to have abandoned the use of `data-name` for complex object ID's.

Illustrator 28.4.1-28.5:

<rect id="mouse_link_n" data-name="mouse/link/n" class="cls-17"...

Illustrator 28.6:

<rect id="mouse_x2F_link_x2F_n" class="cls-17...

This is the same as the old format, before 28.4.1. However, the new stylesheet format is still used (.cls-1 etc.).

——————————

Beginning with Illustrator 28.4, the format of SVG files exported via Javascript are in a very different format.

The following examples are exported with:

options.cssProperties = SVGCSSPropertyLocation.STYLEELEMENTS;
...
doc.exportFile(fileObjSingle, ExportType.SVG, svgOptions);

The AI file looks like this:

The old format looked like this (Illustrator 28.3):

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 27.9.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
	 viewBox="0 0 500 500" style="enable-background:new 0 0 500 500;" xml:space="preserve">
<style type="text/css">
	.st0{clip-path:url(#SVGID_00000050657835777145769900000007173324349283303303_);}
	.st1{fill:#FF000D;}
	.st2{fill:#CA00D5;}
	.st3{fill:#2AEC00;}
	.st4{fill:#F0AB00;}
</style>
<g id="layer_2__x2F__extra_content">
	<g>
		<defs>
			<rect id="SVGID_1_" x="207.75" y="328.25" width="128" height="128"/>
		</defs>
		<clipPath id="SVGID_00000120556236775382720460000010520103355737100182_">
			<use xlink:href="#SVGID_1_"  style="overflow:visible;"/>
		</clipPath>
		<g id="clipped_group" style="clip-path:url(#SVGID_00000120556236775382720460000010520103355737100182_);">
			<rect id="Rectangle_x5F_smaller" x="150" y="270.5" class="st1" width="128" height="128"/>
			<rect id="Rectangle_x5F_Grandé" x="193.5" y="367" class="st2" width="40" height="40"/>
		</g>
	</g>
</g>
<g id="layer_1_200_x25_">
	<g id="group_1__x3E__group_2">
		<rect x="37.5" y="33.5" class="st3" width="116.5" height="116.5"/>
		<rect x="106.25" y="102.25" class="st4" width="116.5" height="116.5"/>
	</g>
</g>
</svg>

The new format looks like this (Illustrator 28.4 & 28.4.1):

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" viewBox="0 0 500 500">
  <defs>
    <style>
      .cls-1 {
        clip-path: url(#clippath);
      }

      .cls-2 {
        fill: none;
      }

      .cls-2, .cls-3, .cls-4, .cls-5, .cls-6 {
        stroke-width: 0px;
      }

      .cls-3 {
        fill: #f0ab00;
      }

      .cls-4 {
        fill: #ff000d;
      }

      .cls-5 {
        fill: #2aec00;
      }

      .cls-6 {
        fill: #ca00d5;
      }
    </style>
    <clipPath id="clippath">
      <rect class="cls-2" x="207.75" y="328.25" width="128" height="128"/>
    </clipPath>
  </defs>
  <g id="layer_2_extra_content" data-name="layer 2 / extra content">
    <g class="cls-1">
      <g id="clipped_group" data-name="clipped group">
        <rect id="Rectangle_smaller" class="cls-4" x="150" y="270.5" width="128" height="128"/>
        <rect id="Rectangle_grandé" class="cls-6" x="193.5" y="367" width="40" height="40"/>
      </g>
    </g>
  </g>
  <g id="layer_1_200_" data-name="layer 1 200%">
    <g id="group_1_group_2" data-name="group 1 &amp;gt; group 2">
      <rect class="cls-5" x="37.5" y="33.5" width="116.5" height="116.5"/>
      <rect class="cls-3" x="106.25" y="102.25" width="116.5" height="116.5"/>
    </g>
  </g>
</svg>

There are many many changes:

• the style definitions
• ID's now strip out characters like / or < instead of replacing them with entities
• the original names are included via data-name tags
• the comment from the 2nd line is now gone
• clipping paths are handled differently

I have built a complex program over many years that depends on the previous format, and it is now completely broken.

Does anyone know how to get back the previous SVG export format?

Does anyone know if this is a bug that will be fixed?

I have filed a bug report with Adobe.

[Doug A Roberts]

This has also broken my workflow.

I used to be able to embed class names based on the Graphical Styles applied to the elements

By @John37426380jlba

Can you share your Save As options? I get class names from graphic styles when using the 'Style Elements' option in 28.4.1:

[elizabethm79439738]

This is also presenting a huge issue for me. It is no longer correctly preserving the svg format needed for our application. I've reverted back to a previous version but will definitely need a different longer term solution. 

[John37426380jlba]

Adobe's stance on this issue is troubling. It's not like the change makes things better (for users, at least). Having more control over the SVG output is a good thing instead of forcing us into a simplified or "dumbed down" export format.

[Doug A Roberts]

This is also presenting a huge issue for me. It is no longer correctly preserving the svg format needed for our application. I've reverted back to a previous version but will definitely need a different longer term solution. 

By @elizabethm79439738

Can you, and anyone else having trouble with the recent changes, please post an example SVG with a description of the undesirable change, along with the exact Save As options you used?

[elizabethm79439738]

My issue is that it is not preserving the correct size however I downloaded the beta illustrator  28.6 and it resolved the issue - when I used save as in beta it correctly preserved the size of the objects. 

[Doug A Roberts]

Did you have 'Responsive' enabled when exporting?

[elizabethm79439738]

No, responsive was unchecked. The save as settings were identical in prior version of illustrator that we are still running on another one of our design macs. I ended up putting beta on the main design Mac and that's solved the issue with the save as to svg. This absolutely needs to be fixed - if I couldn't revert to a previous version or have it working in beta, we would have had to move to an entirely new design program. I wish adobe would put out something official about their plans with it because if it won't end up being fixed in beta once that becomes live, we need to start the process of switching design platforms. 

[elizabethm79439738]

Also - @Doug A Roberts  you posted earlier the change will not be reverted however given that it works correctly in beta doesn't that seem to negate that it won't be reverted? 

[Doug A Roberts]

It depends exactly what change you are talking about. Can you share an example SVG exported from both the general release and the beta showing the difference, as well as sharing your export options?

The 'Save As' SVG code will not be reverted to pre-Export As parity (before 28.4.1). But that doesn't mean there aren't bugs that will be fixed.

[Andy Swift]

There is a second significant change that I forgot to mention in my revised answer. Previously, programmatically exporting an SVG without the option "use artboards" would export an SVG with a viewbox representing the size and placement of the artboard, but include artboard off to the sides. With the new change, the viewbox encloses artwork and the artboard is not used as a reference (when "use artboard" is not set to true).

This is logical, but it might trip people up who suddenly find that their artwork is in the wrong place.

[randomisabel]

This has broken all of our cnc operations and cut processes. We've had to start using inkscape in stead... ugh. Our CNC won't even recognize a SVG file that is opened and then ctrl-S is used to save with no changes lol.... tell me it's "helpful" with those Adobe responses.

[elizabethm79439738]

I downloaded illustrator beta and that has fixed it, but I had to rebuild all my workspaces and that is such a pain. 

[Margaret21803661ajyg]

This also hugely effects my work. Did anyone find a work around for this? I have been just downloading the SVG Code from the preview when you save as. But it is still scrambling some of the way we name things. This hugely effects our software.

[Rik5C45]

This issue has significantly disrupted our company's daily workflow, which has been standardized for nearly 10 years. We have an application that utilizes thousands of SVG files, each containing layers labeled with Color IDs that are now being renamed upon export. Unfortunately, the beta version has not resolved this problem for us. As a result, we have issued an alert advising our team to either not update or revert back to version 28.3 until we find a better solution.

[John37426380jlba]

We don't have thousands, but hundreds, and have the same problem. The only thing we could do as a software company was to write a post-processor application to rework the SVGs. It's a major pain and Adobe's position on this is cofounding. It also reduces our confidence in the product, and we have to assume this will break yet again.

[randomisabel]

We also don't have thousands, but we have enough that this causes a disruption in work flow for us too. Why not just use the W3C standard? Adobe doesn't own SVG, it's an open file type meant for collaboration, not for Adobe to try and build a moat around.
We fortunately have a cooperative group on the production end of signage and have been able to jetison Adobe from that process completely. So their attempt to build a moat has ironically backfired for about half our work which will not use Adobe products moving forward. Given all that privacy stuff that was kicked up last month, probably for the best anyway.

[Doug A Roberts]

Can anyone experiencing workflow issues with recent changes to SVG export please detail exactly what change they're talking about, with examples of code before and after the change (and example files, if possible)?

[Rik5C45]

Upon examining the SVG export file, I found that the software had appended a hyphen ("-") and a number ("1, 2, 3," etc.) after the name of each Object ID ("Layer name") during export. This is significant because our application relies on a basic naming convention—Color 1, Color 2, etc.—and the addition of these characters breaks the functionality of the SVG.

Additionally, the gradient layer is being altered upon export. Our application expects to see only one color with different opacity values at the stop IDs within a gradient. After exporting in version 28.4, additional color values and stops are added, which again breaks the SVG functionality within the application.

I also want to note that changing the encoding to ISO 8859-1, as another user suggested, did correct my issue. However, I noticed that this feature has a warning in the beta version about being removed in a future release.

[Ramtin27248883d2s1]

I have been experenced the same issue as well. 

Previous version's export feature will create a SVG file with much clear code.

  <g id="Bas_Rhin" data-name="Bas Rhin">

            <path id="_29" data-name="29" class="cls-8" d="m678.824,1122..006Z"/>

            <path id="_28" data-name="28" class="cls-8" d="m771.857,697…1.219Z"/>

   </g>

But with the upgrade, I found the "data-name" has been removed

  <g id="Names">

        <path  id="_x31__Languedoc" class="cls-30" transform="translate(1915.202 …

</path>

      </g>

[Ramtin27248883d2s1]

After I upgrade to v29.0, the data-name is back.