Just a minute...(/)
We are currently optimizing your images. Please wait a moment as we ensure the highest quality results for you.
Great, we have successfully compressed your images.
Images Optimized.
Compress SVG Images Online
Remove the metadata, keep the vector: your SVG renders exactly the same
Optimizing...
Compress SVG files by deleting what the editor left behind
Open an SVG in Notepad and you will see the whole thing: tags, numbers, text. That is what the format is. No pixels, no photograph, just instructions for drawing shapes. It matters because it changes what compression means here. Nothing gets squeezed or approximated. The redundant text simply goes, and the drawing is untouched.
Where the weight actually comes from
Almost none of it is the artwork. Export a logo from Illustrator, Figma or Inkscape and the file arrives carrying the editor’s paperwork: a generator comment, a DOCTYPE nobody has needed since 2008, an XML declaration, a metadata block describing the document in RDF, layer names, and a style block full of classes that no element uses. On a real logo we tested, all of that came to about two thirds of the file. The shapes were the small part.
Then there are the numbers. Editors write coordinates at full floating point precision, so a rectangle that sits at 10 and is 180 wide gets stored as 10.000000 and 180.00000000. Multiply that across every point in every path and the decimals alone can outweigh the drawing.
It stays a vector, so there is no quality to lose
This is the part people worry about for no reason. An SVG has no resolution. It is drawn fresh at whatever size it is displayed, whether that is a 16 pixel favicon or a billboard. Removing a metadata block does not change any of that. The file that comes back scales exactly as far as the one you uploaded, looks identical at every size, and is still fully editable in the program you made it in.
What gets removed
The cleanup is conservative by design. It targets things that have no effect on rendering.
| Removed | Kept |
|---|---|
| Editor comments and generator strings | Every shape, path and curve |
| The metadata block and its RDF namespaces | Colours, gradients and opacity |
| DOCTYPE and the XML declaration | Text elements and fonts |
| Definitions nothing refers to | Filters, masks and clip paths in use |
| Empty groups and layers | Transforms and viewBox |
| Excess decimal places in coordinates | Anything that changes what you see |
Why smaller SVGs matter more than smaller photos
An SVG is usually a logo or an icon, which means it sits in the header of every page on a site and loads before anything else. Photos load late and lazily. Icons do not. Trimming a few kilobytes off a header logo is worth more to a page’s speed score than trimming the same amount off an image halfway down the article, because the header is what the browser waits on before it can paint.
One thing worth checking before you deploy
The cleanup shortens the internal id attributes inside the file. References inside the same SVG are updated to match, so gradients, masks and clip paths keep working and the drawing renders exactly as before. What it cannot know about is code outside the file. If your SVG lives in an icon sprite that other pages point at, or if a stylesheet or a script reaches in and grabs an element by its id, those hooks are worth testing after you swap the file in. For a plain logo or an exported icon, which is most SVGs, there is nothing to check.
If your SVG has a photograph inside it
Sometimes an SVG is not really a vector. Place a photo on the artboard in Illustrator, export as SVG, and the picture gets embedded as a long base64 string inside the XML. The file might be two megabytes with a single shape in it. Cleaning the markup will not touch that block, because it is not markup. If your file barely shrinks and it started life with a photo in it, that is why, and the fix is to take the image out and compress it as a JPEG or a PNG separately.
Nothing to set
There are no options, no compression level and no advanced tab. Upload the file, get it back cleaned. Several at once works the same way, and you can take them one by one as they finish or download the whole set as a ZIP.
What happens to your files
Files travel over an encrypted connection, get cleaned, and are deleted from the server an hour later. Nothing is kept, and nothing is used for anything else.
What you get
- Editor metadata, generator comments, DOCTYPE and unused definitions removed
- Coordinates rounded to a sensible precision instead of nine decimal places
- A file that still scales infinitely and still opens in your editor
- Identical rendering at every size, verified against the original
- Batch upload, with one by one downloads or the whole set as a ZIP
- No account, no install, and files deleted from the server an hour later
What’s next?
Working with a logo that also exists as a bitmap? Compress PNG handles the transparent version and Compress WebP the modern one. And if the SVG turned out to have a photograph buried inside it, Compress JPG is where that picture should go.
Frequently Asked Questions
No, and it cannot. An SVG has no pixels and no resolution. It is a set of drawing instructions that the browser follows fresh at whatever size the image appears, so it is exactly as sharp on a phone as it is on a billboard. Cleaning the file removes text that does not draw anything, such as comments and metadata. The shapes, curves and colours are left alone, so the result renders identically at every size.
The paperwork your editor added. Illustrator, Figma and Inkscape all write a generator comment, an XML declaration, a DOCTYPE, a metadata block in RDF, layer names, and often a style block containing classes nothing uses. On top of that, coordinates get written at full precision, so a value of 180 is stored as 180.00000000. On a typical exported logo, all of that adds up to roughly two thirds of the file. What draws the picture is the small part.
Yes. The output is a normal SVG, so it opens in Illustrator, Figma, Inkscape or any text editor exactly like the original. The only difference is that some of the editor’s own bookkeeping is gone, so layer names may not come back the way you left them. The artwork itself is unchanged and fully editable.
Two common reasons. Either it was already optimised, which happens with SVGs exported from tools that clean up on the way out or files that have been through an optimiser before, or the file contains an embedded photograph. That second one catches people out: placing a photo on the artboard in Illustrator and exporting as SVG embeds the picture as a base64 block inside the XML. That block is image data rather than markup, so cleaning the markup leaves it exactly as it was. If a two megabyte SVG hardly moves, open it in a text editor and look for a very long string starting with data:image.
It can, and it is worth knowing before you deploy. The cleanup shortens the id attributes inside the file. References within the same SVG are rewritten to match, so gradients, masks and clip paths keep working and the image renders exactly as before. Code outside the file is a different matter: if a stylesheet targets an element by id, if JavaScript animates a specific node, or if the file is part of a sprite that other pages reference, test those after swapping the file in. For a standalone logo or an exported icon, which covers most SVGs, there is nothing to worry about.
Yes, and the two work well together rather than competing. This cleanup removes text that should not be in the file at all. Gzip, which your web server applies as it sends the file, compresses whatever text is left. Doing both is normal practice and the combined result is smaller than either alone. It is also worth checking that your server actually has compression switched on for the image/svg+xml content type, since some default configurations only cover HTML, CSS and JavaScript.