A client's 1.8MB logo SVG crashed their email builder — the export hid three embedded raster images and a full font subset. Cleaned: 34KB, identical rendering. SVGs are code, and exported code is messy: editor metadata, hidden layers, six-decimal precision, unused defs. This guide shows what to strip safely, what breaks logos (viewBox!), and how to validate at 16px and 200px before shipping.
Part of the image optimization guide. Optimize markup in the SVG optimizer; mint favicons in the favicon generator. Raster fallback logic in formats guide.
What to strip safely (metadata, precision, defs)
- Editor metadata: Illustrator/Inkscape/Figma headers, comments, processing instructions — pure dead weight, often 30–50% of file size.
- Hidden layers and off-canvas art: designers hide drafts instead of deleting; each hidden group ships bytes and sometimes confidential content.
- Coordinate precision: six decimals → one or two.
12.345678to12.35is invisible at every real size and saves ~20%. - Unused defs and gradients: palette experiments never applied — safe to drop when unreferenced.
- Font subsets: embedded fonts for two words of text — convert text to paths for logos, or subset ruthlessly.
The viewBox: touch it and the logo breaks
viewBox="0 0 200 60" defines the coordinate system everything scales from. Delete it and the SVG renders at unpredictable sizes; alter it and aspect ratios skew. Rules: never remove viewBox, never change its numbers unless you understand the transform, always pair with explicit width/height or CSS sizing. The #1 SVG bug I review is a “responsive” logo with viewBox stripped — perfect on the designer's screen, collapsed to 0×150px in production. Validate after every optimization: render at 16px (favicon), 48px (header mobile), and 200px (footer) before committing.
SVG vs PNG: logo delivery rules
| Use SVG when | Use PNG/WebP when |
|---|---|
| Geometric logos, icons, line art | Email signatures and newsletters |
| Anything needing infinite scaling | Social avatars with fixed pixels |
| File under ~50KB optimized | Complex gradients that bloat as vectors |
| Dark-mode variants via CSS | Legacy CMS without SVG upload |
Photographic content as “SVG” (embedded base64 raster) is the worst of both worlds — huge files with zero scalability. If your SVG exceeds 200KB, inspect it: embedded images mean it should have been JPG/WebP all along. For favicons, generate the full set (16/32/180/192/512) from the optimized master with the favicon generator.
Validate: 16px, 200px, dark mode
Three renders catch 95% of breakage: 16px favicon tab (details vanish? simplify paths), 200px header (strokes too thin? bump to 2px minimum), and dark-mode background (dark strokes invisible? add light variant or outline). Also confirm the file opens after stripping — over-aggressive minifiers occasionally eat required namespaces. Keep the unoptimized master archived; re-optimize from it when brand colors change rather than editing minified output.
General guidance only. Complex illustrations with photographic gradients usually belong as WebP — vectorize drawings, rasterize paintings.