How we make a self-contained animated SVG
Every animation this site exports is a single SVG file that animates on its own. No script tag, no animation library, nothing to install. Drop it in an <img>, an email template or a README and it plays. That property is not a feature we added; it falls out of one constraint we accepted early, and the constraint has a real cost worth being honest about.
The constraint: no runtime animation library
The rule is that everything must animate with CSS keyframes or SMIL — the two systems already built into SVG. No JavaScript drives motion, anywhere. That sounds limiting, and it is, but it means the animation is described by the document rather than performed on it. Once the file is written, it needs nothing else to run.
What the file actually contains
A generator is a pure function: it takes a config object and returns a string of SVG markup. Inside that string is the geometry, a <style> block with the @keyframes, and — where the effect needs it — filter definitions. Nothing references an external asset except the webfont, which is an @import the browser resolves.
That last point has a sharp edge worth knowing if you embed one. An SVG referenced through <img src="x.svg"> is loaded in a restricted mode where it fetches no external resources at all — we measured it: zero network requests. The animation still runs, but the @import never resolves, so the text falls back to a system font. If the typeface matters, inline the markup into the page instead of pointing at it.
Why two renders of the same config are identical
Generators are forbidden from calling Math.random or Date.now. Anything that looks random — jitter, flicker, scatter — is derived from the input instead, so the same config always produces the same bytes.
That is not tidiness for its own sake. It makes video export possible: to record an animation the server steps a browser through it frame by frame, seeking the clock rather than racing wall-clock time, and streams the frames into ffmpeg. If the animation drifted between runs, frames would not line up and the golden-frame tests that catch rendering regressions could not exist.
The size difference is not small
Because the file describes the animation instead of recording it, an animated SVG is measured in kilobytes where the equivalent video is measured in megabytes. A text animation that runs a few seconds is typically under 20 KB — smaller than a single photograph, and it stays perfectly sharp at any size because there are no pixels to enlarge.
A GIF of the same animation is often fifty times larger and still looks worse, because GIF has a 256-colour palette and dithers anything smoother than that. Video files compress better than GIF but cannot be transparent in most formats, and they will not scale up. The SVG is the only one of the three that is simultaneously small, sharp and transparent — which is why it is the export to keep as your master, even if you also publish an MP4.
What it costs
No JavaScript means no interaction. An exported animation cannot start when it scrolls into view, respond to a hover, or react to a click — it plays on its own timeline and loops or stops. For a title card or a logo sting that is exactly right. For anything that needs to respond to a user, it is the wrong format and a JS library is the honest answer.
It also rules out effects that genuinely need scripting — physics, anything driven by real input. And the two built-in systems behave differently in ways that matter once you start exporting; CSS keyframes and SMIL are not interchangeable. If you want to see the output rather than read about it, the generator exports an SVG in one click, no account.