SVG

SVG describes vector graphics and related text in XML rather than requiring one fixed raster pixel grid.

Artwork described with geometry and document structure

Geometry, text, gradients, clipping and masks can describe artwork at different display sizes. Intrinsic width/height and viewBox define how its coordinate system maps into a viewport; they are not the same as permanently choosing PNG pixel dimensions.

SVG can also contain scripts, event handlers, foreignObject content and references to other resources. An SVG displayed as an image and an SVG mounted as active page content have different security contexts. Treat an unfamiliar file as untrusted content rather than assuming that a vector image is inert.

Description and accessibility are part of the document

title and desc provide descriptive/accessibility information, while metadata can carry structured provenance or licensing data. Comments can also be meaningful. These should not automatically be treated as disposable bytes.

A restricted SVG platform in PRVKIT

The shared SVG platform accepts a restricted set of shapes, paths, local fragment references, gradients, masks, clipping and text. It refuses scripts/events, foreignObject, animations, filters, external/data/non-fragment references, imported/escaped CSS, DOCTYPE/entities and unsupported namespaces.

Uploaded source is never inserted into live page DOM. SVG to PNG and SVG Optimizer use an image-context renderer; input is capped at 2 MiB and output at 12 MP / 6000px. Dimensionless artwork requires user dimensions. This is not a full SVG-spec implementation or general sanitizer. The Editor has a separate, narrower vector-import scope.

Vector output and raster output serve different needs

SVG to PNG chooses an output resolution and creates raster pixels. Transparency can remain or be replaced with an explicit background. Rasterization does not preserve editable XML geometry or textual provenance.

SVG Optimizer Safe mode preserves all comments, metadata, title/desc and ARIA without legal-wording heuristics. It performs conservative serialization and an independent bounded rendering comparison; a material change blocks download. No aggressive cleanup mode is exposed.

A document language has a different trust boundary

An SVG is text describing artwork, but “text file” does not mean inert content in every environment. The larger specification includes features that can load resources or behave differently depending on how the document is embedded. That is why an image-context renderer and a live inline SVG are not interchangeable security contexts.

PRVKIT's restrictions are product boundaries, not a claim that it implements every SVG feature and then removes all possible danger. A file refused for external references or active constructs needs a genuinely compatible source. Do not treat copying the rejected markup into a page as a valid workaround.

Licensing and attribution are also separate from technical admission. A logo or icon can be structurally supported while still requiring permission to use it. Comments and descriptive fields can contain legitimate credit, so aggressive deletion merely to lower a byte count can damage information that matters.

The viewBox and output dimensions answer different questions

The viewBox describes a coordinate region used to map the artwork into its viewport. Width and height can establish the intended display dimensions, while a dimensionless source may require the user to choose a raster size. A shape can therefore remain mathematically scalable without having one universally correct PNG width.

For raster delivery, choose dimensions based on the destination. A large slide graphic needs a different pixel grid from a small document icon. Rendering more pixels consumes memory even when the SVG source text is tiny. The configured input, node, depth, edge and pixel budgets apply together rather than qualifying every theoretical vector workload.

Aspect-ratio choices deserve inspection. A square viewport around rectangular artwork may include space, crop it under its declared mapping or alter the intended fit depending on the source. Do not assume that changing a pair of dimension fields is equivalent to editing the design deliberately in a vector application.

Text and descriptive elements have independent value

Visible text may depend on available fonts and their metrics. Check the rendered letters, alignment and line endings in the actual output. A text element remaining in the XML does not guarantee that every receiving renderer has the same font, and a rasterized word does not remain editable as text.

Title, description and ARIA information can support accessibility in the appropriate embedding context. Conservative SVG optimization preserves those structures. A PNG export cannot supply equivalent SVG document semantics to a receiving web page automatically, so that page still needs an appropriate text alternative.

A rendering comparison checks visible pixels at chosen dimensions. It cannot establish that every descriptive label is accurate, that a logo is licensed or that every downstream screen reader interprets a future embedding correctly. Keep visual equivalence, document meaning and accessibility integration as distinct review tasks.

Choose optimization or rasterization according to the handoff

Use SVG Optimizer when a supported vector source should remain a vector document. Its safe mode preserves meaningful structures and performs a bounded independent rendering comparison. Modest savings can be the correct result when aggressive simplification would risk changing the artwork.

Use SVG to PNG when the recipient needs pixels. Choose transparency or an explicit background, then inspect text, clipping and thin edges at the intended use size. Keep the vector master so that another raster size can be generated without enlarging an earlier small PNG.

Editor has a separate restricted import subset for editable vector work. A successful shared SVG render is not proof that every gradient, mask or clipping relationship becomes an editable Editor object. Verify the actual product path when editability is the goal.

Check both the saved document and its context

Open the actual result in the receiving application. Confirm dimensions, alpha behavior, important geometry and text. Review source comments or metadata when privacy matters, because optimization deliberately preserves them. Visible names or identifying artwork remain in either vector or raster copies unless changed intentionally.

A download starting is not proof that the file finished saving, and a successful image-context render is not a universal embedding certificate. Retain the original and use PNG when the intended result is a raster copy, keeping the format's capabilities separate from the narrower PRVKIT workflows described here.