SVG Optimizer

What this SVG optimizer changes

An SVG can carry far more source than the picture needs. Design applications add editor metadata, comments, redundant attributes, long numeric forms, repeated declarations, and verbose path notation. An SVG optimizer rewrites that representation while keeping the supported static image intact. The result is still SVG: scalable vector markup that can be linked as an image, served from a site, or opened in a text editor.

This route treats optimize, compress, and minify as the same job because they begin with the same SVG source and end with one smaller SVG file. It does not promise a fixed reduction. Raw chart exports can contain substantial repetition, while a small hand-written icon may already be as compact as the safe policy can make it. When no verified candidate is smaller, the receipt says the file is already compact and does not offer a larger replacement.

Structure matters beyond matching pixels

A screenshot comparison cannot see every important part of an SVG document. The root viewBox controls how the graphic scales. An id may connect a shape to a gradient, clip path, mask, marker, or <use> element. The same ID system connects aria-labelledby and aria-describedby to a title or description. Renaming or dropping one of those nodes can leave the picture looking right in one preview while breaking reuse or accessibility elsewhere.

The local worker therefore reparses the finished output and compares those relationships before the page calls it structurally verified. Literal IDs stay literal. Fragment references, accessibility relationships, title and meaningful description text remain part of the receipt. The tool also preserves the root viewBox instead of trading responsive scaling for a few more bytes.

A second check uses the browser's own renderer

Structural equality alone is not visual proof. After the worker finds a smaller candidate, the page loads source and output through local blob image URLs and draws both into the same canvas at two bounded sizes. Every red, green, blue, and alpha channel must match exactly. The optimized download remains unavailable while that comparison is pending, if the browser cannot decode either image, or if even one channel differs.

The preview uses an <img> decoding context. The SVG is never inserted as live inline markup, an object, an iframe, or HTML. The source preview appears only after the worker accepts the static subset. This order matters: rendering untrusted SVG before checking its references would turn a convenience preview into an execution or network surface.

The accepted subset is deliberately static

Ordinary shapes, paths, text, gradients, clipping, masks, fragment references, and static style declarations can be optimized. Scripts, event-handler attributes, animation, transitions, document type and entity declarations, embedded browsing content, and external resources are rejected before preview. CSS at-rules are also outside this version, including imports, media rules, and font-face declarations. External and data URLs in CSS are not fetched or flattened.

Self-contained raster images are the narrow exception: allowlisted Base64 PNG, JPEG, GIF, WebP, or AVIF image data may remain embedded. Active SVG or HTML data is not accepted, and an external image URL is still outside the contract. That distinction preserves a common self-contained chart-export pattern without opening a remote fetch or nested active-document path.

Rejection is different from sanitization. Silently deleting an event handler or remote font might produce a calmer document, but it would not be equivalent to the source. The error names the unsupported boundary so you can remove that behavior in an editor, flatten it with a workflow that understands the dependency, or deliberately choose a different output. This page never calls a behavior-changing cleanup a lossless optimization.

Why several safe profiles are attempted

A single aggressive preset is not safe for every export. Numeric precision and path rewriting can make a large difference to file size, but they can also move a curve or text edge far enough to change raster pixels. The optimizer tries a documented sequence of conservative profiles, verifies each candidate, and selects a smaller one only when the structure contract still holds. The receipt lists the attempts instead of hiding the search behind one generic “optimized” label.

This is also why there is no exact 15 KB box. Structural cleanup has a natural floor. Hitting an arbitrary byte target after that point would require visible simplification, dropping content, rasterizing detail, or pretending a target is guaranteed when it is not. If the source is code embedded in a larger document, first use the HTML formatter to isolate it without lowercasing SVG's case-sensitive names, then optimize the standalone SVG here.

File and pasted markup follow the same policy

Choose a local .svg file, drag one onto the counter, or paste markup from a text editor. All three paths send the same SVG string to the same worker. A file is decoded with strict UTF-8 handling, so invalid bytes receive a specific error instead of becoming silent replacement characters. A textarea creates new UTF-8 text and normalizes line endings as browsers always do, which is why pasted input is named separately in the receipt.

Large files are not refused. The page shows the shared memory advice before inspection and still leaves the action available. Starting a new file, editing pasted source, clearing the counter, canceling, or retrying ends the current worker generation and revokes old preview and download URLs. An older result cannot reappear beside newer source after a slow job finishes.

Optimization is not conversion or editing

This tool returns SVG. It does not trace a bitmap, turn SVG into PNG, draw or simplify shapes by eye, repair a Cricut project, fetch a remote URL, or install itself into Figma, Illustrator, or Inkscape. If the destination truly needs a text data URI, remember that SVG is already text: the image to Base64 guide explains why Base64 usually makes SVG larger rather than smaller.

Optimization has no useful reverse direction. Removed comments and editor metadata cannot be reconstructed from a compact file, and expanding whitespace would create bytes without restoring authoring intent. Keep the original as your editable source; treat the verified download as a delivery copy for the web or an application bundle.

No upload and no hidden remote fallback

File reading, static preflight, optimization, output parsing, previews, and pixel comparison run in this tab. The optimizer code itself is a versioned same-origin resource fetched only after you start inspection. That request is the same for every visitor and contains no SVG bytes, filename, IDs, text, or output. There is no upload endpoint and no third-party CDN fallback for an SVG the browser finds difficult.

You can verify that boundary instead of taking it on faith. The local processing guide explains what browser network tools can prove and where their evidence stops. The optimizer's own receipt addresses a different question: whether this particular output became smaller while its measured structure and rendered pixels stayed the same.