Resize SVG & fix viewBox

How it works

The tool edits the root <svg> element only — width, height, viewBox and preserveAspectRatio — and never touches the drawing inside. Because SVG is resolution-independent, that is all resizing an SVG ever needs to be: change the declared box and every path re-renders sharp at the new size, with no resampling and no quality loss. Type into a field to set the attribute; clear a field and the attribute is removed from the file, which is itself a useful operation. The lock keeps width and height proportional to the file's intrinsic ratio while you type, the result is shown as formatted markup before you commit it, and everything runs in your browser — nothing is uploaded. Applying writes the shared document, so the resized file flows straight into the editor or an export.

viewBox and width/height do different jobs

The viewBox defines the coordinate system: which rectangle of the drawing's own units is visible. width and height define the box on the page that rectangle is mapped into. Confusing the two is behind most SVG sizing bugs. A file with only width and height is pinned at that size — scaling it in CSS crops rather than zooms. A file with only a viewBox scales to whatever contains it. A file with both renders at the declared size by default and scales when CSS says otherwise. That is why this tool treats them as separate controls rather than one "size" field, and why removing an attribute is as important as setting one. The viewBox guide works through which attribute wins in which context.

The two ways to rebuild a viewBox

From width/height writes 0 0 w h using the dimensions currently in the form. That is the right move for the common export bug — a file with width="48" height="48" and no viewBox at all — because those editors drew the content against that box from the origin; you are writing down the coordinate system the file always assumed.

From content asks the browser to measure where the drawing actually is: the file is mounted invisibly for a frame, getBBox() reports the true bounding box of everything painted, and that becomes the viewBox. This is the fix when the drawing sits nowhere near the origin — a shape cut out of a larger illustration, an icon whose coordinates start at 400 — and it doubles as a crop-to-content: whatever empty margin the export left around the artwork is gone, which matters when an icon has to sit optically tight in a button. One caveat is inherent to getBBox(): it measures geometry, not paint, so stroke overhang, markers and filter effects like shadows fall outside the derived box. Widen the numbers by hand when the artwork paints past its skeleton.

Making an icon scale to its container

The most requested "resize" is not a size at all — it is making a fixed-size icon fluid. The recipe is two steps on this page: make sure a correct viewBox exists (derive one if not), then press Clear width & height and apply. With only a viewBox left, the SVG sizes to its CSS container — width: 1em makes it track the text size, 100% fills a layout slot, and the same file serves every size from favicon to hero. The preserveAspectRatio field covers the remaining case where container and viewBox proportions differ: the default xMidYMid meet letterboxes, slice fills and crops, and none stretches. If you leave the field empty the attribute stays out of the file, which is almost always right.

When to use it

An icon that refuses to scale: fixed dimensions and no viewBox is the usual cause, and the fix is derive-from-dimensions, then clear width and height. A drawing that renders off-centre or clipped after editing, where the viewBox no longer matches where the content actually sits: derive from content. A print-bound export whose pt or mm dimensions come out the wrong size on screen: retype them as plain numbers. And setting an exact box before a PNG export — though if the SVG itself is fine and only the PNG needs to be bigger, set the pixel size in that tool instead and leave the file alone.

Common problems

• The derived box clips strokes. getBBox() measures geometry, not paint — a stroke overhangs its path by half its width on every side, and shadows and markers are not counted at all. Pad the numbers after deriving.
• Setting width and height changes nothing on the page. CSS wins over attributes. The attributes only provide the default size for contexts with no stylesheet — an <img>, a download, an email.
• Deriving from dimensions produced an empty view. The content is not drawn at the origin, so 0 0 w h frames the wrong region. Derive from content instead — it starts from where the drawing actually is.
• The drawing is distorted after applying. With the lock off, the width/height ratio no longer matches the viewBox ratio, and preserveAspectRatio decides how the mismatch resolves. Either relock, or set it deliberately.
• The numbers inside the paths didn't change. By design — resizing SVG means changing the mapping, not rewriting coordinates. The drawing's own units are untouched, which is why the operation is exact and reversible.