SVG Tools — Optimizer + SVG to PNG / JPG / WebP / PDF

SVG is the format that holds the modern web's logos, icons, charts, and illustrations together, and yet most authoring workflows leave it in poor shape by the time it reaches production. Designers export SVGs from Figma, Illustrator, Sketch, or Inkscape, and the resulting files are usually 30–80% larger than they need to be — full of editor-specific metadata, redundant XML processing instructions, hidden layers, generated comments, IDs that nothing references, transformation matrices that could be flattened, paths that could be merged. Hand-optimization is tedious. The canonical solution is SVGO, a Node.js library that has been the industry-standard SVG optimizer for over a decade, and the canonical hosted UI for it has been Jake Archibald's SVGOMG. This tool builds on the same SVGO engine and adds the conversion side — SVG to PNG, JPG, WebP, and PDF — that SVGOMG deliberately leaves out, so the entire SVG hand-off workflow can happen in a single page.

The optimizer side ships three presets that map to real-world workflows. Safe runs only metadata-stripping plugins: it removes comments, editor namespace data, the XML processing instruction, empty elements and empty attributes, and minifies inline `<style>` blocks. It does not touch your paths, IDs, or visual structure, which makes it the right choice when the SVG will be edited again later or when the file uses scripted manipulation that depends on stable identifiers. Default runs SVGO's `preset-default` with one important override — `removeViewBox` is disabled, because dropping the `viewBox` attribute breaks responsive sizing in HTML and CSS, and the SVGO default of removing it is a footgun many engineers have hit in production. Aggressive layers the default preset with extra optimizations: `convertStyleToAttrs` moves CSS into XML attributes for better gzip compression, `convertShapeToPath` and `mergePaths` collapse rect/circle/ellipse elements and combine adjacent paths, `sortAttrs` improves byte-level repetition for compression, `removeDimensions` lets the host control sizing instead of the SVG, `removeOffCanvasPaths` drops geometry outside the visible viewBox, and `reusePaths` deduplicates identical path data into reusable definitions.

SVGO runs entirely in your browser. The library ships a dedicated browser bundle (`svgo/browser`) that this page lazy-loads only when you switch to the Optimize tab, so the rest of Omnvert does not pay the ~500 KB download cost up front. Once loaded the engine works against the bytes in memory: nothing is sent to a server, nothing is logged, and you can verify the absence of network activity in the browser DevTools panel. For sensitive material — internal mockups, unreleased branding, paid customer assets, anything under an NDA — this matters. Most online SVG optimizers upload your file to a backend and return the result; SVGOMG itself runs in the browser, but adding the conversion side means another tab, another upload, and another vendor to trust. This tool collapses that into one page with the same privacy guarantees throughout.

The conversion side answers the four questions designers and engineers actually ask after the SVG is clean. SVG → PNG is the universal raster fallback, used everywhere a vector can't go: legacy email clients (Outlook still does not render SVG inline), older CMS thumbnails, OG images for social media, app store screenshots. SVG → JPG is the right choice when the SVG content is photographic-looking and you need a smaller file than PNG would produce — JPEG's lossy compression beats PNG's lossless deflate by 5–10× on continuous-tone content, and you trade a small quality loss for a meaningful bandwidth saving. SVG → WebP is the modern best-of-both-worlds: lossy compression at the JPEG end, lossless with alpha at the PNG end, supported by every modern browser since 2020. For most production raster output today, WebP is the right default. SVG → PDF is the print and archival format: clean, vector-quality output that survives any zoom level and slot into design tooling, document workflows, and engineering documentation.

How the rasterization works under the hood is worth a paragraph because it directly affects the quality of your output. The browser exposes SVG decoding through the `Image` and `<canvas>` APIs: a Blob URL of the SVG text is loaded into an `Image`, and the image is drawn onto a canvas element at the target dimensions. The canvas is then re-encoded via `canvas.toBlob` to JPEG, PNG, or WebP. The dimensions you set drive both the canvas size and the encoded raster, so for sharp output on high-DPI screens you should render at 2× or 3× the displayed size. The Scale control on this page does exactly that — it multiplies the canvas dimensions while keeping the SVG identical, which produces output that stays crisp on Retina displays without requiring you to do the math. For PDF the page renders to canvas at the chosen scale, encodes to PNG, and embeds the PNG into a fresh PDF document sized in points (the print unit, where 1 px ≈ 0.75 pt) using `pdf-lib`. The result is a single-page PDF that prints at the right physical dimensions and renders identically on every PDF viewer.

There are subtleties with SVG that the simple browser pipeline cannot fully solve, and being honest about them is more useful than pretending they do not exist. First, system fonts: when an SVG declares `font-family: "Inter"` and Inter is not installed on the rendering machine, the browser falls back to a default font and the rasterized output looks different from the authoring tool. The page detects inline font-family declarations and surfaces a warning so you can choose to convert text to outlines in your design tool before exporting. Second, external resources: SVGs sometimes reference images, gradients, or filters via absolute URLs (xlink:href to https://, `<image href="https://…"/>`, `url(https://…)` in CSS). Browser rendering of these requires a network fetch and CORS-permissive headers; when those are absent, the asset silently does not render. The page detects external references and warns you. Third, scripts: `<script>` elements inside an SVG are executed by some renderers but not by `<canvas>` rasterization; SVGO removes them by default and we surface a warning when present. Fourth, complex filters and clipPaths: most modern browsers handle these well, but very old or unusual filter chains can produce slightly different output between engines.

On the optimizer side there is a single fact worth knowing about SVGO's defaults. SVGO 4 — released in 2024 — strips the `viewBox` attribute by default if both `width` and `height` are present. This is mathematically valid for static SVGs but breaks responsive sizing the moment the SVG is dropped into a CSS context that wants to scale by aspect ratio. Every preset on this page leaves `viewBox` intact for that reason. If you genuinely want it removed for a one-off use case, the workflow is to run the optimizer here and then strip the attribute manually. The opposite case is also worth noting: if your SVG has only a `viewBox` and no `width`/`height`, browsers happily scale it to fill its container, which is usually what you want for icon systems and inline illustrations.

For the conversion side, the most important number is the output dimension. SVGs are vector, which means they have no inherent pixel dimensions — the size you pick at export determines both file size and visual quality. For a logo displayed at 200×200 in a header on a Retina display, render at 400×400 (2×) or 600×600 (3×) and let the browser downscale on display; this is sharper than rendering at the displayed dimensions because of the way subpixel sampling works. For an OG image at 1200×630, render at exactly that size — OG images are not high-DPI and 1200×630 is the canonical canvas. For a print-bound PDF at 8.5×11 inches, set the SVG to 816×1056 px (96 DPI × inches) and the page produces a PDF at the right physical size automatically. The Scale control multiplies whatever pixel dimensions you specify, which is the right knob for high-DPI raster but irrelevant for PDF because PDFs are vector-equivalent at any zoom.

Quality settings are the second important knob on the conversion side. JPEG and WebP both support a quality parameter from 0 to 100, where 100 is essentially lossless and 0 is unrecognizable. For SVGs converted to raster, the right number is usually higher than for photographs because SVGs often have sharp edges and flat colors that compress poorly at low quality settings. The defaults on this page (90 for JPEG/WebP) match the typical production setting for vector-derived raster. If you are converting a photograph-derived SVG (rare but possible — sometimes an SVG wraps a `<image>` element with embedded raster), you can drop quality to 78–82 like a normal JPEG without visible loss. PNG has no quality parameter because it is a lossless format; the trade-off there is dimensions, not quality, and pairing PNG conversion with the Scale control gives you the lever you need.

Privacy is worth being explicit about because it is the single biggest reason to prefer this tool over hosted alternatives. The SVG bytes you drop here are read into JavaScript memory using the standard File API, parsed with `DOMParser`, optimized with SVGO running in the browser, rendered to canvas with `Image` and `drawImage`, and encoded back through `canvas.toBlob` or `pdf-lib`. None of those APIs make outbound network requests for the file content. The browser DevTools Network tab will show zero requests during optimization or conversion — you can verify it yourself, and you can run the entire workflow offline after the page has loaded once. There is no cloud account, no server-side caching, no vendor risk to manage. For agencies, in-house design teams, and freelancers handling client assets under NDA, this is the only category of SVG tooling that does not require a vendor-risk review.

A few practical patterns are worth committing to muscle memory. First, run Default on every SVG before checking it into a repository — it removes editor metadata that bloats the file with no upside, and the savings are usually 20–40% on raw exports. Second, run Aggressive on production-bound SVGs that no one will edit again — icons in an icon system, illustrations in a marketing page, hero graphics — because the additional savings (another 10–15%) compound over a typical site's worth of SVGs. Third, when converting to raster, always render at 2× for screens unless you have a specific reason not to; the file size cost is small and the visual quality difference is large. Fourth, prefer WebP over JPEG for raster output on the modern web — WebP supports both lossy and lossless modes plus alpha transparency, beats JPEG and PNG on file size, and is supported in every browser shipped since 2020. Fifth, treat PDF output as the print fallback, not the web fallback — PDFs are heavy, do not embed in pages, and lose the indexability of an SVG element.

There are a handful of things this tool deliberately does not do, and naming them is more honest than pretending the tool covers everything. It does not produce vector PDFs from SVG — the conversion path renders to high-DPI raster and embeds in PDF, which is the most reliable approach but loses the infinite-zoom property of a true vector PDF. If you need vector PDF specifically (engineering drawings, large-format print), an Illustrator or Inkscape export is still the better tool. It does not handle multi-page SVG, because SVG is a single-page format by spec; if you have several SVGs to combine into a multi-page PDF, run each through here and merge with the PDF Tools. It does not handle animated SVG (SMIL or CSS animations) — when converting to raster, only the first frame is captured, which is the standard behavior for image-export tools. And it does not optimize embedded raster inside an SVG — if your SVG contains a `<image href="data:image/png;base64,…"/>` element, the embedded PNG is left untouched; run the embedded PNG through the Image Compressor separately if you want to shrink it.

This tool pairs naturally with the rest of Omnvert's image utilities. After optimizing and converting, the Image Compressor can re-encode raster output to AVIF for an additional 20% saving on web-bound assets. The Crop tool reduces image area before compression, which compounds savings on the raster side. The [EXIF Remover](/tools/exif-remover) is unnecessary for SVG-derived raster (browser canvas encoders never write EXIF), but useful when blending SVG output with photographs in the same workflow. The [Background Remover](/tools/background-remover) is the inverse direction — raster to alpha, useful when an SVG-derived asset needs to be composed with an external photograph. All of these run in the browser with the same privacy guarantees, so an entire SVG-to-production workflow can happen in a single tab without a single byte going to a third-party service.