Lottie limitations: what doesn't survive the export

What Lottie drops on export

Per LottieFiles' own docs and years of open issues, these After Effects features don't export — or export broken:

* One honest note on expressions: AE2CSS samples them for the core transform properties — position, scale, rotation, opacity — not arbitrary effect-parameter or random/wiggle expressions. We'd rather under-promise there than oversell.

See it live: kept vs dropped

Three effects Lottie can't export, running as CSS on the left — and what Lottie gives you for the same layer on the right. No player, no JavaScript; these are just CSS.

The Lottie panels are static on purpose: with the effect unsupported, the layer exports flat (glow, sweep) or, for a pure expression, doesn't move at all unless you bake keyframes by hand first.

Glow — the effect people miss most

Glow is the most-requested effect Lottie doesn't have — "why doesn't Glow export?" has sat open since 2021 (lottie-web #764, #2484). The usual fix, pre-rendering it to a raster PNG, throws away exactly what Lottie was chosen for: vector scalability, and a small file. AE2CSS instead reproduces Glow as a native radial-gradient bloom + stacked drop-shadow — vector, zero runtime. Drop Shadow is the same story: broken or cropped in Lottie (#553, #926), native in CSS.

Expressions — ignored, not exported

Bodymovin doesn't evaluate expressions, so expression-driven motion exports static unless you convert every property to keyframes by hand first. AE2CSS instead evaluates the value over time (valueAtTime) for the core transform properties — position, scale, rotation, opacity — and bakes a compact set of keyframes automatically. Honest limit: transform motion only, not arbitrary effect-parameter expressions, and it skips random/wiggle (which can't be baked to a clean loop).

The file grows with length — CSS doesn't

An argument that rarely gets made and matters a lot: a Lottie file stores the animation data itself, so every keyframe and every extra second of a baked path adds bytes — real files reach past 1.3 MB, before the ~46 KB player. A CSS export is declarative: it stores the rules you authored and the browser interpolates, so a two-second loop and a ten-second one are the same size. Size scales with the keyframes you wrote, not with duration.

Illustrative — exact Lottie sizes depend on the artwork, but the direction is the point: Lottie grows with the animation, CSS grows with the keyframes you wrote. (The CSS motion running elsewhere on this page is a few hundred bytes and doesn't get bigger if you loop it for an hour.)

It's not just effects — SEO & accessibility

A Lottie file is a JSON data blob with no semantic meaning, so search engines can't index it and screen readers can't read it. Teams regularly hit this trying to make Lottie text ADA/WCAG-compliant. Animation exported as real HTML/CSS is part of the DOM: it can carry semantic markup, be crawled, and honor prefers-reduced-motion out of the box. If you're investing in the page for search or accessibility, that's a decisive difference.

The cross-platform promise, honestly

One source on web, iOS, and Android is Lottie's real strength — but parity isn't guaranteed: the same file can render differently on Android, and an OS update has broken it before (iOS 18). If you ship to native apps, Lottie is still the right tool — just budget for per-platform testing.

So what do you do?

• Web-only motion that uses glow, shadow, blend, mattes, or expressions → export to CSS; the effect survives and the file stays small.
• Intricate vector art that also runs in native apps → Lottie, and test per platform.
• Not sure which effects survive? The table above is the short version; the fuller comparison is in Lottie vs CSS and the alternatives guide.

FAQ