Initializing... drag & drop files here
Supports: SVG
<defs> automatically — the precision slider is the only knob you typically adjust per-file.SVG files are XML text, which means most of the bytes designers ship are invisible to users: editor namespaces from Illustrator and Figma, indentation, comments, default attributes, and path coordinates carried to 12 decimal places. Compression is purely structural — visual output is byte-identical to the original at sensible precision settings. Typical savings range from 30-70% before gzip, and another ~30% on top of that once your CDN serves the file gzipped or brotli-compressed.
| Property | SVG | PNG | WebP |
|---|---|---|---|
| Type | Vector (XML) | Raster | Raster (lossy or lossless) |
| Scales without quality loss | Yes | No | No |
| Typical icon file size | 0.5-3 KB | 5-30 KB (plus @2x/@3x) | 3-15 KB |
| Transparency | Yes | Yes (alpha) | Yes (alpha) |
| CSS-stylable (color, hover) | Yes | No | No |
| Animation | SMIL or CSS | No | Limited |
| Browser support | Universal | Universal | Chrome, Firefox, Edge, Safari 14+ |
| Best for | Icons, logos, diagrams | Screenshots, pixel art | Photos, complex raster art |
For UI icons and logos, SVG almost always wins on both file size and rendering quality at any DPI. WebP and PNG remain better for photographs and complex raster artwork where vector representation would actually be larger.
XConvert applies SVGO defaults plus the precision setting you choose. The default preset runs 33 plugins; the high-impact ones for size:
| Plugin | What it strips |
|---|---|
| removeDoctype, removeXMLProcInst | DOCTYPE and <?xml ?> headers — browsers infer these |
| removeMetadata, removeEditorsNSData | Illustrator/Figma/Sketch namespace data |
| removeComments | <!-- --> blocks |
| cleanupNumericValues, convertPathData | Rounds coordinates to your precision setting; default is 3 decimals |
| removeUselessDefs, removeHiddenElems | Gradients, filters, and layers defined but never referenced |
| collapseGroups, mergePaths | Flattens redundant <g> wrappers and merges compatible path segments |
| convertShapeToPath, convertEllipseToCircle | Picks the shorter representation for each shape |
| minifyStyles, inlineStyles | Inlines and minifies internal CSS |
| Precision | Decimals kept | Best for | Trade-off |
|---|---|---|---|
| 1-2 | 1-2 decimals | UI icons, simple logos, flat illustrations | Maximum savings; possible "wobble" on smooth curves |
| 3 | 3 decimals (SVGO default) | Most icons and illustrations | Strong size reduction, no visible artifacts |
| 4-6 (XConvert default 6) | 4-6 decimals | Detailed illustrations, hand-drawn paths | Conservative — safest if you can't visually inspect output |
| 7-10 | High precision | Engineering drawings, maps, CAD exports | Minimal savings; preserves sub-pixel detail |
Structurally, yes — removing metadata, comments, and unreferenced definitions changes nothing visible. Path data reduction depends on the precision setting. At precision 3 and above, output is visually identical to the original. At precision 1-2, very smooth curves on complex paths may show minor changes; this is configurable per file via the slider.
The bulk is usually path data, not metadata. A logo traced from a complex Illustrator artwork can carry thousands of anchor points where a hand-drawn equivalent would use dozens. Re-tracing in a tool like Figma or simplifying paths in Illustrator (Object → Path → Simplify) often saves more bytes than any optimizer can. Embedded raster images inside SVG (base64 <image> tags) also cannot be vector-compressed — extract them as separate PNG/WebP files.
CSS animations and SMIL animations on referenced elements are preserved by SVGO defaults. However, animations that target IDs may break if cleanupIds renames or removes them — XConvert's default keeps IDs that are referenced by <use> or animation targets. If you script SVG with JavaScript by ID, test the output before deploying.
Yes. Inline SVGs become part of your JavaScript bundle, so every byte ships to every visitor. Run compression once on the exported file, paste the minified output into your component, and you've shaved 50-70% off the bundle cost. Tools like svgr apply SVGO automatically during build — but starting from an already-clean source is friendlier to code review.
Gzip and brotli further shrink already-minified SVG by roughly 25-35% because XML compresses well. The two stack: SVGO removes structural waste; gzip removes textual redundancy. A 50 KB raw export → 15 KB after SVGO → about 5 KB over the wire after gzip is a realistic chain for a mid-complexity illustration.
That makes sense if the asset will be displayed at exactly one fixed size and you don't need crispness on high-DPI displays — see SVG to PNG or SVG to WebP. For icons, logos, and anything that scales (responsive layouts, retina screens, print), keep SVG and compress it. Going the other direction with PNG to SVG only works cleanly for graphics with flat colors and clear edges.
SVG itself is supported in every browser shipped this decade — Chrome, Firefox, Edge, Safari, mobile browsers, even IE11 for static SVG. Compression only removes data the SVG spec marks as optional. If a file works before optimization, the compressed version works in the same browsers.
Yes — and that's where the biggest savings show up. Design-tool exports carry the most overhead: editor namespaces, layer metadata, default attributes, and high-precision coordinates. A Figma icon export of 4 KB routinely drops below 1 KB after optimization. If you also need raster fallbacks, see compress PNG for the equivalent on rasterized exports.
Files upload to xconvert for processing, are converted, and are deleted shortly after. No sign-up, no watermark, no public sharing of your file. For maximum privacy with sensitive logos or unreleased brand assets, you can also self-host SVGO locally via npm.