What optimisation can remove
An SVG optimiser strips comments, metadata, editor namespaces and unnecessary whitespace, and rounds
coordinate decimals. Measured on a small file with a comment and three-decimal coordinates:
106 bytes before, 94 bytes after, with the rectangle unchanged in position
(x="1.234" became x="1.23"). The saving is small on a simple file and larger
on an export from a design tool, where editor metadata can be most of the document.
What it must not do is change rendering. Rounding coordinates changes geometry at the last decimal;
that is invisible at normal sizes and can matter for a technical drawing. Removing a viewBox
changes how the file scales; removing a style can change colours. An optimiser is safe when it removes
metadata and whitespace, and needs care when it touches numbers. Keep the original and compare the
rendered result, not just the byte count.
viewBox, width and height
viewBox defines the coordinate system and the aspect ratio; width and
height define the rendered size. They are not the same thing. An SVG with a viewBox but
no width/height scales to its container; one with fixed width/height ignores the container unless CSS
overrides it. A missing viewBox makes the coordinate system the rendered box, which is why an icon can
look cropped when it is resized.
For an icon, a square viewBox and no fixed dimensions is usually the flexible choice: the page decides the size, and the vector stays sharp. For a standalone image, set width and height as intrinsic dimensions and keep the viewBox, so it has a default size and still scales.
Rasterising: choosing a resolution
Converting SVG to PNG means choosing a pixel size. The right size is the size at which it will be displayed, multiplied by the device pixel ratio if it is a high-density screen. A 24-pixel icon rendered at 24 pixels is sharp on a standard display and soft on a 2× display; rendering at 48 and letting CSS show it at 24 is the usual fix. For print, the target is physical: at 300 DPI, a 4-inch image needs 1,200 pixels wide.
Once rasterised, the image is pixels; scaling it up again interpolates and blurs. That is the trade: SVG is resolution-independent and larger to download; PNG is a fixed grid and predictable. Use SVG for icons and diagrams in a page, PNG for destinations that cannot render SVG (some email clients, older tools) and for pixel-exact output.
Accessibility and the document
An SVG is a document, so it can carry a <title> and a <desc> for
assistive technology, and role="img" with an accessible name where it is used as an
image. An icon that is purely decorative should be hidden from the accessibility tree
(aria-hidden="true") rather than given a redundant label. Optimisers vary in whether they
keep these elements; a title removed for bytes is a real accessibility loss, so check the output.
Text in an SVG is text, not paths, until an editor converts it. Keeping it as text makes it selectable, searchable and translatable, at the cost of depending on the viewer's fonts. Outlining it makes the rendering exact and the text inaccessible. For a logo, either is defensible; for a diagram, keep the text.
Printing: pixels versus paper
Paper sizes are physical, not digital. An A4 sheet is 210 × 297 mm; at 300 DPI that is about 2,480 × 3,508 pixels, and at 72 DPI it is 595 × 842. The same image file printed on different paper has a different physical size unless the DPI is set explicitly. The paper-size reference lists the dimensions at any DPI, which is the bridge between an SVG's viewBox and the printed page.
For a print workflow, keep the vector until the last step: optimise the SVG, then rasterise at the target DPI and paper size. Rasterising first and scaling the PNG to the page loses the sharpness the vector was for.