How to Resize an SVG Without Losing Quality

Searching “resize SVG without losing quality” reveals a happy misunderstanding: SVGs can’t lose quality from resizing. They’re drawing instructions, re-rendered fresh at every size. The real question hiding underneath is “which numbers do I change?” – and that has a satisfyingly simple answer.

The three numbers that control SVG size

<svg width="24" height="24" viewBox="0 0 24 24">

viewBox defines the internal coordinate system – the design space. 0 0 24 24 means “this artwork lives on a 24×24 grid.” Path coordinates are expressed in this space. You almost never change it to resize.

width and height set the default display size – how big the SVG renders when nothing else says otherwise. This is what you change.

The magic is in the relationship: display size scales the viewBox space to fit. width="240" on a viewBox="0 0 24 24" renders everything 10× – mathematically, losslessly, at render time.

Resizing, case by case

Make the file render at a specific size: change width/height attributes – width="64" height="64" – done. Visual route: set the artboard size in the Studio and export.

Make it responsive (the web pattern): delete width and height, keep the viewBox:

<svg viewBox="0 0 24 24">

Now CSS controls size completely (width: 100%, width: 2rem, anything) and the SVG fills whatever container it’s given. This is the correct form for inline icons and illustrations – the fixed attributes only fight your stylesheet.

Scale within a page: plain CSS on the element (transform: scale() or width rules) – the browser re-renders the vector, no quality cost.

Get a fixed-pixel raster: that’s an export, not a resize – render PNG at the exact target via SVG to PNG (1×–8× scales). Resizing the PNG afterward is where quality loss actually lives; always re-render from the SVG instead.

The failure modes (and their one-line fixes)

“My SVG won’t resize at all.” It has width/height but no viewBox – so the browser has no coordinate mapping to scale. Add one matching the natural size: viewBox="0 0 [width] [height]". Some tools export this broken state; it’s the #1 cause of resize frustration.

“It resized but it’s squashed.” The viewBox ratio and the display ratio disagree (e.g., square viewBox forced into a wide box). Match the aspect ratios – or learn preserveAspectRatio if you genuinely want non-uniform fitting.

“It scaled but the strokes look wrong.” Stroke widths live in viewBox units, so they scale with the artwork – usually what you want. A 2-unit stroke at 10× display is visually 20px. If you need visually-constant strokes across sizes, that’s vector-effect="non-scaling-stroke" – a niche tool worth knowing exists.

“Small sizes turn to mush.” Not a resize bug – a design reality. Detail has a perceptual floor; icons need testing at target size. The Studio previews at 16/28/48px simultaneously for exactly this.

What about changing the viewBox?

Changing the viewBox doesn’t resize – it reframes: which region of the coordinate space is visible. That’s cropping, panning, and zooming, covered in the SVG cropper guide. The mental model that makes everything click:

viewBox = the camera. width/height = the screen. Paths = the world.

Resize the screen freely; the world re-renders perfectly every time. Move the camera only when you mean to reframe the shot.