2026-10-30
Vector vs raster is the first thing to settle before you open a compression tool, because it decides whether compressing does anything at all. A raster file stores a grid of pixels, so it carries a fixed width and height and its size grows with both. A vector file stores drawing instructions instead, so it has no resolution and its size follows the number of shapes and anchor points in the artwork. That is why one logo can be 40KB as an SVG and 2.4MB as a PNG, and why cutting the size of each is a different job.
Raster image compression works on the pixel grid. Lossless methods such as stripping metadata, merging duplicate palettes and repacking the deflate stream leave every pixel alone and usually return 10 to 30 percent. Lossy methods go further: JPEG drops high-frequency detail and chroma resolution, WebP and AVIF add better prediction on top, and quantization lowers the color count. What none of them can do is add detail back. Scale a 400px-wide photo up to 1600px and you get a bigger file holding the same blur. Resolution is the ceiling, and compression only decides how tightly you pack up to it.
When to compress vector files is mostly a question of what the file carries. An SVG exported from Figma or Illustrator often ships with editor metadata, hidden layers, unused gradient definitions, coordinate precision to ten decimal places, and a base64 preview bitmap nobody renders. Strip all that and a 120KB icon can land near 25KB with no visible change. If the SVG was already cleaned, gzip or brotli at the server handles the rest, and you can skip the local pass entirely.
SVG vs PNG compression runs along two different paths, and which one wins depends on the picture. A flat logo with six colors stays sharp at any size and often lands under 10KB as a vector. A photograph has no shapes to describe, so forcing it into vector form produces a huge file that looks worse. The ranges below come from files we ran through the tool.
Vector vs raster file size stops being a puzzle once you ask what the image is made of. Hard edges, flat fills and text are shapes, and shapes belong in a vector file. Gradients, shadows, noise and anything a camera captured are pixels, and pixels belong in a raster file. Most real projects mix both: an SVG logo over a JPEG background. Compress each in its own lane and the total drops further than any single pass.
Start by asking whether the file is a grid of pixels or a list of shapes. Raster files respond to quality and dimension changes, so set the output width first and only then pick a quality value; the reverse order wastes time. Vector files respond to cleanup, so remove what the editor added and let the server compress the text. Both kinds deserve one last look on the real background, at the size you actually ship.
The full walkthrough for SVG cleanup is in /blog/compress-svg-without-breaking, and /blog/compress-png-without-losing-quality covers the raster side in detail. If you are weighing raster formats, /blog/png-vs-jpg-differences lays out the trade-offs, and /blog/image-resolution-vs-file-size explains why shrinking dimensions beats lowering quality on photos.
No. Photo compression works on pixels and trades visual detail for bytes. Vector files are text, so the useful steps are removing editor metadata, rounding coordinate precision and deleting unused definitions. Running a photo compressor over an SVG does nothing.
Usually an embedded raster preview, or a tracing pass that turned every pixel into a shape. A photo traced into vector paths produces thousands of anchors and a file several times larger than the original. Check for a base64 block first.
Cleanup passes do not. Rounding coordinates to two decimals can shift a path by a fraction of a pixel, and converting text to outlines changes how it renders, so keep live text where you can.
No. Photographs are continuous tone, and describing them as shapes produces a huge file with visible artifacts. Set the dimension first, then use WebP or AVIF for a far smaller result.