A New SVG-to-Video Tool Is a Reminder: Rendering Remote SVG Is a Trust Boundary

What Willison shipped

In an August 16, 2026 post, Simon Willison describes the latest iteration of his markdown-svg-renderer, a browser tool for sharing Markdown transcripts that embed SVG. You can paste Markdown directly, or point the tool at a URL — a CORS-friendly host or a GitHub Gist — which produces a bookmarkable page with the source URL encoded in the hash. SVG code blocks render as a tabbed interface: a live Rendered tab (including animations), plus PNG and JPEG export tabs. The newest addition, shipped this month, adds video export — the tool loads a 30MB+ build of ffmpeg.wasm to compile animation frames into an MP4, entirely client-side.

Why rendering someone else's SVG isn't risk-free

SVG is XML, not a passive image format. It can carry <script> elements and event-handler attributes — onload, onmouseover, onclick — that execute the moment the browser parses the document. OWASP's XSS Filter Evasion Cheat Sheet lists working SVG-based payloads for exactly this reason, and its companion Cross Site Scripting Prevention Cheat Sheet treats SVG the same as any other markup that needs output encoding or sanitization before it reaches the DOM.

A tool that only rendered SVG you pasted yourself would carry limited risk — you're attacking your own browser tab. The URL and Gist modes change that: the content comes from wherever the link points, which can be edited after the fact by anyone with write access to that Gist or host. Sharing a bookmarkable link means sharing a pointer to content you no longer control.

What the writeup doesn't say

Willison's post is a feature update, not a security writeup, and it contains no mention of SVG sanitization, iframe sandboxing, or Content-Security-Policy. That's not an accusation — plenty of well-built tools omit this detail from a changelog post — but it's worth naming as a gap rather than assuming it away. For a solo-maintainer developer tool built to solve a specific personal problem (Willison's is sharing pelican-riding-a-bicycle SVGs), feature velocity understandably comes before formal threat modeling.

The practical checklist

For any team building a similar "paste a URL, render the content" tool, the defenses are well established:

• Sanitize with an SVG-aware allowlist, such as DOMPurify's SVG profile, before the markup ever touches the DOM.
• Render untrusted SVG inside a sandboxed <iframe> (no allow-scripts) rather than inline in the host page.
• Set a strict Content-Security-Policy — script-src 'none' for the rendering surface, at minimum — so even a missed sanitizer bypass can't execute.
• Treat every Gist- or URL-fetched document as untrusted input, on the same footing as any other remote fetch that lands in a browser context.

Why this matters beyond one tool

SVG-carrying features are everywhere now — diagram generators, chart exporters, AI-assisted drawing tools, and Markdown renderers that quietly support embedded SVG. Each one that accepts a remote URL or user-supplied file inherits the same question: what happens when the SVG isn't the one you expected? That's a design decision worth making explicitly, not a default a framework gives you for free.