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 result says the file is not smaller and does not offer a larger replacement.

Four steps, no settings

Choose or drop an SVG file and it is optimized right away; pasted markup waits for a click on Optimize SVG, since the text may still be half finished. The result shows the picture before and after side by side, the size before and after, and a short note for anything you should know about the output. Then download the SVG or copy its code. To try another file, choose one above the result, or Start over. There is no precision slider and no profile menu, because the checks below decide which version is safe to hand back.

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 that check. 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. At each size, the largest red, green, blue, or alpha difference may be at most 40 and the mean across all channels may be at most 1. Those measured bounds admit equivalent edge antialiasing — 36 peak and 0.733 mean in the checked Chromium fixture — while a 0.4-unit moved edge reached 214 and fails. The optimized download remains unavailable while that comparison is pending, if the browser cannot decode either image, or if either bound is exceeded. When the smallest version fails, the next smallest is compared, and the first one that passes becomes the download. When none passes, no download is offered.

The preview uses an <img> decoding context. The SVG is never inserted as live inline markup, an object, an iframe, or HTML. The before and after preview appears only after the worker accepts the static subset and the pixel check has finished. 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. Animation, transitions, document type and entity declarations, embedded browsing content, and external resources other than image links 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.

Allowlisted Base64 PNG, JPEG, GIF, WebP, or AVIF image data may remain embedded. Active SVG or HTML data is not accepted. An <image> that links to an http or https address is kept in the output, because it is part of your file, and the page says so by URL. It is never fetched here: the previews decode SVG as an image, where browsers load no external files, which also means the pixel check cannot see that picture.

Scripts are removed and listed, not refused

An SVG meant for a web page should not run code, and a script, an onclick-style event handler, or a javascript: link never paints a single pixel. The optimizer therefore removes those three kinds of active content before optimizing and lists each one by name, for example “Removed 1 <script> element”. The downloaded file contains none of them, and the preview is built from the cleaned source, so nothing in your file can run on this page.

Removal is never silent and never called equivalent. The picture is unchanged, but the file no longer behaves like the original when it is opened directly or placed inline, and the byte savings include what was removed. Content whose removal could change the picture — animation, embedded HTML, CSS at-rules — is still refused with a named reason, because deleting it would be an edit this page cannot verify.

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 keeps a smaller one only when the structure contract still holds. You do not pick a profile: the smallest version that passes both checks wins, and the result names it in one line instead of hiding the search behind a 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 page, 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 downloads as pasted.optimized.svg.

Large files are not refused. The page shows the shared memory advice before you optimize and still leaves the button available. Starting a new file, editing pasted source, Start over, or canceling 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, draw or simplify shapes by eye, repair a Cricut project, fetch a remote URL, or install itself into Figma, Illustrator, or Inkscape. When the destination needs fixed pixels rather than an editable vector, use the separate SVG to PNG converter; it asks for exact raster dimensions and keeps the proportions locked. 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. When the optimized logo is meant to become a site icon, the favicon generator builds favicon.ico, the browser PNGs and the Apple Touch icon from that one SVG.

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 choose a file or click Optimize SVG. 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 result answers a different question: whether this particular output became smaller while its measured structure and rendered pixels stayed the same.