A Lottie alternative for developers (and how to render to MP4)

Lottie is genuinely great at one specific thing: tiny interactive vector animations that ship inside a web or mobile app and play back at runtime. It's the right tool for a "loading" spinner, an icon hover state, a heart-tap microinteraction.

It's the wrong tool for most of the things teams reach for it for. Specifically: brand stings, ad creative, social videos, dashboards, anything that ends life as an MP4. The reason: Lottie's runtime is a player, not a renderer.

The Lottie pipeline, plainly

1. Animator opens After Effects.
2. Animator exports .json via the Bodymovin plugin.
3. Developer drops .json into the app, instantiates lottie-web (or its native equivalent).
4. At runtime, lottie-web parses the JSON, walks the timeline, and draws each frame to SVG or canvas.

For an interactive UI animation, this works. For a video, it doesn't, because the source-of-truth is the After Effects file. Lottie is downstream from After Effects.

If the design needs a tweak, the path is: open AE, edit, re-export JSON, swap JSON. That round-trip is fine when the animator and developer are the same person (rare) or when the animation never changes (also rare). For everything else, it's a friction tax.

The HTML alternative

The same kinds of animations Lottie does well — vector shapes, paths, easing, color — are also things HTML and CSS do well. SVG covers the shape side; CSS covers the easing and transforms. If the source is a .html file:

• The developer edits it directly.
• Version control diffs are legible.
• The render-to-MP4 path is the same as anything else: feed it to a deterministic renderer.

The MP4 question

This is where the comparison gets sharp. Lottie does not export to MP4. The official path is "render in After Effects, export, ship the MP4." Which means Lottie is not in the loop at all for the video output — you're using AE to produce both the Lottie JSON and the MP4.

The HTML path produces an MP4 directly. Open the HTML in a deterministic renderer, set duration and fps, render. Same source, two outputs (the live web animation and the MP4) — no duplication, no drift, no separate AE file.

Where Lottie still wins

Three cases:

• In-app microinteractions. A 200ms hover bounce on a button. Lottie's runtime is tiny and tuned for this.
• Animator-first workflows. If your animator only knows AE and the dev team is small, Lottie is a reasonable handoff format.
• Existing libraries. If you already have a hundred Lottie files in a design system, the rip-and-replace cost may not be worth it.

For new work where the team has HTML/CSS skills, the simpler model wins.

A migration heuristic

If a Lottie file does any of these, port it to HTML:

1. Renders to MP4 at some point in its life. The MP4 is your real artifact; cut out the middleman.
2. Has to be A/B tested or variant-rendered. Editing HTML is faster than re-exporting AE.
3. Lives in your marketing site or email, not your product. No mobile runtime to worry about; HTML wins on file size at this point.

If a Lottie file is only a tiny interactive microinteraction inside a native app, leave it alone.

The longer "render in code, not a timeline" argument is in HTML is the next video codec. The kinetic-typography patterns Lottie users tend to reach for are in kinetic typography for headlines.

A working definition

Lottie is a player. HTML + a renderer is a render path. For UI animations, you want a player. For video, you want a render path. Picking the right one for the job is a much bigger productivity win than picking the right framework once you've already committed to the wrong category.