I have a 50MB SVG file

Preview:

and I have created this zoom in and out functionality to zoom in and out of SVG image but it gets extremely laggy, unfortunately.

Is there a way to convert this large file SVG file into a smaller SVG file Size.

Thus, I was wondering whether we can adjust the resolution of SVG image by stopping the vector graphics processing (High CPU Usage, very laggy) with a button which hopefully will stop SVG file from lagging when zooming in and out or panning it?

Any help or suggestions will be extremely useful for me :)

(I have tried a lot of online pressor but unfortunately, all of them cannot handle this immense file size).

I have a 50MB SVG file

Preview:

and I have created this zoom in and out functionality to zoom in and out of SVG image but it gets extremely laggy, unfortunately.

Is there a way to convert this large file SVG file into a smaller SVG file Size.

Thus, I was wondering whether we can adjust the resolution of SVG image by stopping the vector graphics processing (High CPU Usage, very laggy) with a button which hopefully will stop SVG file from lagging when zooming in and out or panning it?

Any help or suggestions will be extremely useful for me :)

(I have tried a lot of online pressor but unfortunately, all of them cannot handle this immense file size).

• javascript
• html
• jquery
• css
• svg

• 1 No. Vector files, like SVG, do not have a "resolution". That's what allows you to zoom in and out without getting pixelization. Perhaps you should convert this to a bitmap file (like PNG) for your zoom purposes. – Tim Roberts Commented Mar 11, 2023 at 7:02

1 Answer 1

SVGs can be huge for many reasons:

1. unnecessarily high coordinate precision (see explanations below)
2. embedded pixel/raster image data included as data URI <image href="data:image/png;base64..."> – so your svg can actually be a pixel image (maybe not well optimized) wrapped in a svg file
3. document overhead e.g introduced by proprietary meta data
4. embedded fonts similar to included images - you also have a huge base64 encoded data chunk
5. hidden elements: most applications won't remove hidden layers/elements when exporting
6. duplicate or obsolete elements, unnecessary/unused style definitions (e.g caused by not well optimized API/script output)
7. overly specific attributes (including default values like fill="black" that could be omitted)
8. plexity: if the file contains ten thousands of elements – a high resolution raster image often provides a smaller file size as well as a better rendering performance

SVG/vector floating point accuracy vs raster resolution

The floating point accuracy can be considered as a kind of equivalent to pixel/raster resolution.

This is important if you're minifying/optimizing a svg by rounding or calculating down scaled values (e.g using a tool like SVGOMG):

1. Optimize large svg element

A svg element spanning across 1000x1000 units with a coordinate precision of e.g 8 decimals can safely be down scaled.
Quite likely you could reduce accuracy by using integer values.

2. Optimize small svg element

The image above shows an font Awesome icon.
Left: original size ~512x512
Right: scaled (recalculated) to 25.6x25.6; rounded to integers

So, you can upscale elements infinitely without a loss of quality.
But when rounding down (or scaling down via recalculations) vector coordinates you must respect the element's level of details – otherwise you'll get distortions due to rounding errors.

<p>Original - unnecessarily large</p>
<svg  viewBox="0 0 1000 1000">
<path d="M999.9999 499.99995C999.9999 776.14152399 776.14152399 999.9999 499.99995 999.9999C223.85739951 999.9999 0 776.14152399 0 499.99995C0 223.85739951 223.85739951 0 499.99995 0C776.14152399 0 999.9999 223.85739951 999.9999 499.99995Z"/>
</svg>
<p>Scaled down - rounded to 1 decimal; all relative mands</p>
<svg  viewBox="0 0 100 100">
<path d="M100 50c0 27.6-22.4 50-50 50s-50-22.4-50-50s22.4-50 50-50s50 22.4 50 50z"/>
</svg>

<p>Original</p>
<svg viewBox="0 0 512 512">
    <path d="M328.4 393.5C318.7 402.6 303.5 402.1 294.5 392.4C287.1 384.5 274.4 376 256 376C237.6 376 224.9 384.5 217.5 392.4C208.5 402.1 193.3 402.6 183.6 393.5C173.9 384.5 173.4 369.3 182.5 359.6C196.7 344.3 221.4 328 256 328C290.6 328 315.3 344.3 329.5 359.6C338.6 369.3 338.1 384.5 328.4 393.5zM144.4 240C144.4 231.2 147.9 223.2 153.7 217.4L122.9 207.2C114.6 204.4 110 195.3 112.8 186.9C115.6 178.6 124.7 174 133.1 176.8L229.1 208.8C237.4 211.6 241.1 220.7 239.2 229.1C236.4 237.4 227.3 241.1 218.9 239.2L208.1 235.6C208.3 237 208.4 238.5 208.4 240C208.4 257.7 194 272 176.4 272C158.7 272 144.4 257.7 144.4 240V240zM368.4 240C368.4 257.7 354 272 336.4 272C318.7 272 304.4 257.7 304.4 240C304.4 238.4 304.5 236.8 304.7 235.3L293.1 239.2C284.7 241.1 275.6 237.4 272.8 229.1C270 220.7 274.6 211.6 282.9 208.8L378.9 176.8C387.3 174 396.4 178.6 399.2 186.9C401.1 195.3 397.4 204.4 389.1 207.2L358.9 217.2C364.7 223 368.4 231.1 368.4 240H368.4zM0 256C0 114.6 114.6 0 256 0C397.4 0 512 114.6 512 256C512 397.4 397.4 512 256 512C114.6 512 0 397.4 0 256zM256 464C370.9 464 464 370.9 464 256C464 141.1 370.9 48 256 48C141.1 48 48 141.1 48 256C48 370.9 141.1 464 256 464z"></path>
  </svg>

<p>Scale down - insufficient accuracy: rounded to integers</p>
<svg viewBox="0 0 25.6 25.6">
    <path d="M 16 20 c 0 0 -1 0 -2 0 c 0 0 -1 -1 -2 -1 c -1 0 -2 0 -2 1 c 0 0 -1 1 -2 0 c 0 0 -1 -1 0 -2 c 1 -1 2 -2 4 -2 c 2 0 3 1 4 2 c 0 0 0 1 0 2 z m -9 -8 c 0 0 0 -1 0 -1 l -2 -1 c 0 0 -1 -1 -1 -1 c 0 0 1 -1 1 -1 l 5 2 c 0 0 1 1 1 1 c 0 0 -1 1 -1 1 l -1 0 c 0 0 0 0 0 0 c 0 1 -1 2 -2 2 c -1 0 -2 -1 -2 -2 l 0 0 z m 11 0 c 0 1 -1 2 -2 2 c -1 0 -2 -1 -2 -2 c 0 0 0 0 0 0 l -1 0 c 0 0 -1 0 -1 -1 c 0 0 0 -1 1 -1 l 5 -2 c 0 0 1 0 1 1 c 0 0 0 1 -1 1 l -2 1 c 0 0 0 1 0 1 l 0 0 z m -18 1 c 0 -7 6 -13 13 -13 c 7 0 13 6 13 13 c 0 7 -6 13 -13 13 c -7 0 -13 -6 -13 -13 z m 13 10 c 6 0 10 -5 10 -10 c 0 -6 -5 -10 -10 -10 c -6 0 -10 5 -10 10 c 0 6 5 10 10 10 z"></path>
  </svg>

Optimize huge plots from CAD applications

Probably, your graphic was intended be used for something like a construction sign so a rather huge print/output size.

If you created the plot yourself:

• search for export options like "scale to fit" a smaller print/plot output size (e.g. to scale it down to a size of US Paper or DIN A4)
• maybe your application allows to reduce the output floating point precision/accuracy
• you might also try to use an optimized DFX/DXW to svg converter like nano
• maybe you could at least split different layers like text labels, lines, legend etc. to separate svg files to make them more editable (without crashing while rendering).
  Usually you need to delete layers to prevent them from being included in the svg export - make sure to save enough backup states.

If you have received the file from an architect/client:
Maybe the creator can sent a more pact file.

If you've succeeded to split layers you might end up with let's say 3–4 separate svg files:
Now you could try to use an optimizer like SVGOMG again.
You could also try to open the files in inkscape to remove excessive groups often bined with a lot of unnecessary transforms like transform="matrix(1 0 0 1 0 0)" (doesn't transform anything):

<svg viewBox="0 0 1000 1000">
  <g id="i-will-never-need-this-id-again" transform="matrix(1 0 0 1 0 0)" data-ment="unnecessary">
    <g id="i-will-never-need-this-id-again-nested1" transform="matrix(1 0 0 1 0 0)" data-ment="unnecessary">
      <g id="i-will-never-need-this-id-again-nested3" transform="matrix(1 0 0 1 0 0)" data-ment="unnecessary">
        <g id="i-will-never-need-this-id-again-nested4" transform="matrix(1 0 0 1 0 0)" data-ment="unnecessary">
          <path d="M999.9999 499.99995C999.9999 776.14152399 776.14152399 999.9999 499.99995 999.9999C223.85739951 999.9999 0 776.14152399 0 499.99995C0 223.85739951 223.85739951 0 499.99995 0C776.14152399 0 999.9999 223.85739951 999.9999 499.99995Z" fill="black" stroke-width="0" stroke="none" clip-rule="evenodd" fill-rule="evenodd" stroke-miterlimit="10" />
        </g>
      </g>
    </g>
  </g>
</svg>

<svg viewBox="0 0 1000 1000">
<path d="M999.9999 499.99995C999.9999 776.14152399 776.14152399 999.9999 499.99995 999.9999C223.85739951 999.9999 0 776.14152399 0 499.99995C0 223.85739951 223.85739951 0 499.99995 0C776.14152399 0 999.9999 223.85739951 999.9999 499.99995Z" />
</svg>

A more stripped down code editor is handy for inspecting these presumably bloated files (e.g for windows notepad++). Whatever you use: better disable all code highlighting or code auto pletion.

Optimize rendering performance

Placing the graphics via <img> tag also improves rendering performance since the 10.000+ vector elements won't be added to the DOM tree.

If the optimized result is still too slow see also this post
"Create interactive map-like experience for big SVG file (non-map)"