An SVG image and an SVG document have different powers
Untrusted SVG needs a policy for every rendering route. Image embedding restricts capabilities, while direct navigation and interactive documents differ.
By 
Paul. Architecture and infrastructure
Accepting an SVG upload requires deciding where that file may become a document. If the product only needs a picture, rendering it as an image resource can restrict capabilities that an interactive document would have. That choice must cover the file's other routes too. A constrained thumbnail does not establish what happens when somebody opens the original URL.
This November 2026 retrospective starts with Simon Willison's 26 October 2024 account. He described SVG embedded through an image element and reported different behavior on direct opening. His account is evidence about his demonstration, not a test performed for this article or a certification of every browser and upload service.
Start with the feature the customer needs
A proposed supplier portal might accept logos for an order summary. The business needs scalable artwork, perhaps a faithful print rendering, and a preview beside the supplier's name. It may have no need for scripts, clickable controls or external resources inside the artwork. Those are illustrative requirements, not an implemented portal.
Define those requirements before selecting an embed method. Copying SVG markup into the page, displaying a URL as an image and opening that URL as a document are different operations. A file extension cannot tell a reviewer which authority the product grants. The review needs the actual route from uploaded bytes to rendered content.
The distinction also changes procurement questions. “Supports SVG” says little about whether originals are downloadable, whether previews are generated or whether staff can open the source in a new tab. Each behavior can have value, but each belongs in the interface description and security policy.
What the dated specification distinguishes
The SVG 2 Candidate Recommendation dated 4 October 2018 supplies the historical specification context. Its conformance chapter distinguishes secure static and secure animated processing modes. Both disable script execution, external references and interactivity; the latter permits declarative animation. “Image” therefore does not necessarily mean “unmoving.”
The chapter expects these restricted modes for raster-like image uses, including HTML image elements and CSS image values. Direct viewing and document embedding have different processing expectations, subject to applicable restrictions. The specification is a framework for reasoning about capabilities, not proof that a particular deployment has implemented every restriction correctly.
The current MDN guide to SVG as an image separately describes image-context restrictions and distinguishes document uses such as object, iframe and embed. It is current documentation consulted for this retrospective. Do not substitute its present guidance for an unverified compatibility claim about a particular browser in October 2024.
Follow the original beyond the thumbnail
For the proposed portal, write down every way the uploaded object can be reached. The order page may use an image element while a “view original” link navigates directly to the same file. An administrator may inspect it through another interface. An export might embed the original into a document. The thumbnail decision does not automatically govern those later uses.
An especially misleading reassurance is that scripting was absent in the preview. That observation, if verified in a real project, would establish behavior for that preview context. It would not establish that the bytes had been sanitized or that direct navigation had the same restrictions. The system needs a policy for the original artifact independently of its display on one page.
Where the original is retained, consider its serving origin, authentication relationship, response policy and intended download behavior. Avoid giving untrusted interactive content the same authority as the application merely for convenience. These are architectural recommendations requiring review in the actual environment, not a complete set of headers supplied by this article.
Choose preservation or transformation deliberately
Rasterizing an upload can produce a preview whose capabilities fit a picture-only feature. It may also lose selectable text, sharp scaling or details important to the customer. The conversion tool still processes untrusted input and needs resource limits and maintenance. A PNG preview is therefore a product trade-off, not a blanket statement that the upload pipeline is safe.
Sanitization is another option when the product must retain some SVG structure. Define the allowed subset and choose maintained tooling for that purpose. Removing an obvious script element by hand is insufficient evidence that all active or external behavior has gone. The policy must cover the features actually admitted, and later changes to that subset deserve review.
Retaining the original for later editing may be useful even if users see only a transformed preview. Keep those artifacts distinct so a later feature does not accidentally serve the original under assumptions established for the preview. Record what the transformation preserves and what it intentionally discards. A customer should know which file is suitable for print or editing.
The real objection is interactivity
An engineering diagram may need links, selectable objects or scripting. In that case, reducing everything to a passive image would fail the feature. The answer is a deliberate document design with appropriate origin separation and policy, plus an account of what that document may access. Image-mode restrictions cannot provide capabilities they intentionally remove.
The conclusion also has limits beyond scripting. Image processing can consume substantial resources, and an upload still needs size limits, access checks and storage rules. A specification's secure processing mode describes a capability set; its name does not guarantee that every possible threat is absent. The business must evaluate the entire path through the product.
No malicious SVG, live HTML demonstration or browser experiment was created or executed for this article. A project-specific verification plan should use authorized, controlled checks of each intended rendering route and record the exact browsers and policies involved. The evidence must match the route being promised to users.
For custom software development, make “where can this upload become an active document?” part of the feature brief. The useful deliverable is a clear decision about preview, original and interactive use. SVG can serve all three jobs, but the capabilities granted for one should never be assumed to describe the others.