SVG Input and Re-execution
This chapter details the tool's data loading and conversion execution. It accepts one SVG file or text input at a time. By dragging and dropping a file into the dashed area under "Original data input" or selecting it via dialog, the internal FileReader API reads the data as text and reflects it in the text area below.
You can also paste code directly from the clipboard. Loading and conversion are executed in the browser using DOMParser.
The first parsing happens automatically immediately after loading a file. However, caution is required if you toggle the deletion settings on the left panel or manually edit the code in the text area.
To apply new settings or changes, you must click the "Perform optimization" button again. Toggling switches without clicking the button will not update the output or preview.
If invalid XML is entered, an "Invalid SVG format" error appears. If loading or parsing fails, the previous successful output is deleted, ensuring no old cleaned data is left behind.
Five Deletion Rules
The deletion process consists of five independent rules that search the parsed DOM tree to remove specific elements or attributes. These can be toggled individually via UI switches.
First, "Delete editor metadata" removes nodes like metadata, sodipodi:namedview, and inkscape:grid that do not affect rendering, while retaining title and desc.
Second, "Delete namespace/attribute" scans and removes custom attributes. Third, "Delete empty groups" recursively removes <g> tags that have no child nodes or only contain blank text, but only if they have no attributes (groups with id or transform are retained).
Fourth, "Delete XML comments" uses regular expressions right after serializing from the DOM tree; comments are deleted only when the checkbox is selected.
Fifth, "Delete script elements/events" performs a limited deletion of script tags, matching localName, and attributes starting with on.
Formatting and Text Spacing
After removing unnecessary tags and attributes, you can choose between "Beautify" and "Compress" modes for the output SVG string.
In "Compress" mode, the tool uses a regular expression to find whitespace between tags (>\s+<) and replaces it with ><. This strips line breaks and indentation to pack the string, though it does not measure actual network compression or display speed.
In "Beautify" mode, the tool counts element hierarchy levels and inserts a line break and two spaces of indentation for each level.
This reconstructs the string to make the code structure easier for humans to read.
While SVG specifications dictate that whitespace within text elements directly affects layout spacing, the current formatSVG implementation detects text, tspan, textPath, and xml:space attributes.
If they are present, the formatter does not reformat the text layout and retains the serialized layout for those specific elements.
However, users should verify their output, as other deletion rules and serialization processes may still affect the final appearance of the SVG.
The tool prioritizes keeping the internal whitespace of text nodes untouched during beautification, but checking the output visually is recommended to confirm that inter-tag modifications or other cleanup routines have not altered the intended text positioning or spacing.
Reading Size Reductions
Upon completion, the output panel displays the "Original size", "After optimization" file size, and the "Reduction rate". These values are calculated by assigning the original and reconstructed strings to UTF-8 Blob objects and comparing their size properties in bytes.
The reduction rate is calculated as (Original size - After optimization) / Original size * 100, displayed to one decimal place.
Removing editor metadata significantly increases this rate.
However, this tool only performs structural deletions of specified tags and attributes. It does not include advanced path optimization algorithms like SVGO.
It will not perform mathematical alterations to the drawing data, such as decimating Bezier anchor points, rounding decimal coordinates, or converting between absolute and relative coordinates to reduce characters.
Therefore, already clean code or files dominated by path data may see little reduction, or even a size increase due to formatting and serialization.
Preview vs. Save Differences
The right output panel features "Preview" and "Code" tabs. The "Preview" tab lets you visually check how the cleaned SVG renders in the browser.
This area uses the SafeHtmlPreview module, rendering the SVG within an iframe with a sandbox attribute and a restricted Content-Security-Policy (CSP) that blocks inline scripts and external resources.
However, these strict restrictions are only temporary measures for the UI display. The unrestricted code copied to your clipboard via the "Copy code" button or downloaded as cleaned_vector.svg via "Save file" does not inherit the CSP headers or preview limitations.
The saved string simply applies the five deletion rules and your chosen formatting. The copy operation relies on the navigator.clipboard.writeText API, and it displays a success message only after the promise resolves and the copy action completes, while also implementing a catch block to handle and display any errors that occur during the copying process.
This ensures that the user is accurately informed about the status of the clipboard transfer.
Limitations of Non-Sanitization
The "Delete script elements/events" option is provided merely as a feature to organize SVG files; it is not a complete, security-focused sanitizer.
It only performs a limited deletion of script tags, matching localName, and on attributes. The restricted sandbox output used for the preview is entirely separate from the actual exported file.
It does not guarantee the detection and blocking of all malicious code, such as javascript: pseudo-protocols embedded in href attributes or crafted, invalid vector data.
References to external resources may also remain fully intact.
The tool's conversion logic simply parses the provided string into a DOM within the browser, deletes specified nodes, and serializes it back.
Since the output SVG file is not guaranteed to be safe for inline embedding on a public website, you must use a dedicated XSS prevention library based on your system's requirements when deploying it publicly.