SVG Optimizer & Viewer

about this tool

SVGO, in the browser

The optimiser is SVGO — the same library behind most build-tool SVG plugins — running from its browser build, fetched the first time you paste or drop a file, so nothing is uploaded. It applies SVGO's default preset: editor metadata and comments go, the XML prolog goes, default attribute values go, empty groups and unused definitions go, coordinates are rounded to the precision you set, shapes become shorter path data, paths merge and groups collapse. Two things are guaranteed on top of the preset: the viewBox is never removed, because an SVG without one stops scaling, and <title> and <desc> — the image's accessible name and description — are removed only if you tick the option, by adding those plugins explicitly.

The other options are the ones people reach for: multipass repeats the passes until nothing changes (a little smaller, a little slower); pretty indents the output for reading rather than shipping; remove width/height drops the fixed size from the root so the image fills whatever box it is given; precision sets the decimals kept in coordinates, where 3 is usually invisible and 1 is visibly lumpy on small icons.

Before, after, and what the network sees

Both versions are previewed side by side as <img> elements — the safe way to show an SVG you did not write, since nothing inside an image can run — and measured in bytes and, where the browser supports CompressionStream, gzipped bytes, which is the figure that matters for a file served over the web. The contents panel reports what the markup holds: paths, groups and ids, whether it has a size, a title, embedded styles, raster images (which vector optimisation cannot shrink), external references (which will not load from a data URI) and script, which is flagged in red.

Data URIs

The optimised SVG is offered as a URL-encoded data URI, a base64 one, a CSS background-image declaration and an <img> tag. URL-encoding here is the compact kind: only <, >, #, %, {, } and & are escaped, and double quotes become single so the URI sits inside url("…"); it beats base64 by about a third on almost every file.

Limits

SVGO is a size tool, not a sanitiser: scripts and event handlers survive optimisation and are only flagged. Text is kept as text; converting it to outlines needs the font and is not done here. Raster images embedded in the SVG are passed through unchanged. Some hand-authored files depend on ids or structure that the default preset simplifies — check the preview, and if something has moved, lower the ambition with multipass off or a higher precision. Files are processed on the main thread, so a multi-megabyte export will pause the page for a moment. Nothing is stored.

To use the cleaned markup in a React component, HTML / SVG → JSX rewrites the attributes for you. To hand a raster version to something that cannot take vectors, SVG → PNG / JPG.

questions

What does optimising an SVG remove?

Editor metadata and comments, the XML prolog, default attribute values, empty groups and defs, unused namespaces and IDs; it rounds coordinates to a set precision, converts shapes to shorter path data, merges paths and collapses nested groups. Exported files from Illustrator, Figma or Inkscape typically shrink by half or more without any visible change.

Why does the tool keep the viewBox?

Because an SVG without a viewBox cannot scale: it is drawn at its width and height and clipped or padded in any other box. Older SVGO presets removed it when width and height matched, which broke responsive icons everywhere, so this tool never does. Remove width and height instead, with the option provided, if you want the image to fill whatever box it is given.

Should I strip the <title>?

Only if the image is decorative. The <title> element is the SVG’s accessible name, read by screen readers when the SVG is inline, and <desc> is its longer description. They cost a few bytes. The tool keeps them unless you tick the option to strip them.

Which is smaller, a URL-encoded or a base64 data URI?

URL-encoded, almost always. Base64 inflates everything by a third; URL-encoding escapes only the handful of characters that would break a URL or a CSS string — <, >, #, %, braces, ampersand — and swaps double quotes for single so the whole thing fits inside url("…"). Both are understood by every browser.

Is it safe to preview an SVG from an unknown source?

Here, yes: the preview is an <img> element, and browsers never run scripts inside an image. The danger is pasting an untrusted SVG inline into a page, where a <script> or an onload attribute does run — the tool flags files that contain either. Optimising does not remove scripts; it is a size tool, not a sanitiser.