In this article
A Lottie is a JSON file describing a vector animation. Shapes, transforms, keyframes. A runtime library reads it and redraws the animation live on screen. There are no video frames in it, which is why a full screen animation can weigh eight kilobytes and stay sharp on any display.
Where it came from
Lottie started as Bodymovin, an After Effects plugin that exported an animation's layers and keyframes as JSON instead of rendering to video. Airbnb built runtimes that could read that JSON and redraw it natively on iOS, Android and the web, then released the lot as Lottie in 2017.
The name comes from Charlotte Reiniger, the German animator who pioneered silhouette animation. The After Effects lineage is still visible in the JSON, which is why the field names read like AE concepts. ks for transform, ip and op for in and out points, shape layers with paths and trim paths.
What is inside the file
At the top level a Lottie declares its frame rate, its in and out points in frames, how big the artboard is, a version string, an assets array for images and precomps, and a layers array.
Layers are the substance. Each has a type, a transform block holding position, scale, rotation, opacity and anchor, and keyframes on any animatable property. A keyframe carries a time, a value, and Bezier handles describing how it eases to the next one.
Nothing is turned into pixels unless you deliberately embed an image. The runtime evaluates the keyframes for the current time and draws vector paths, every frame, on the device.
Lottie against the alternatives
The comparison that matters depends entirely on what you are optimising for.
- Against GIF: a Lottie is usually far smaller, supports full alpha and unlimited colours, and stays sharp at any size. GIF wins only on universal support, because it plays anywhere with no runtime.
- Against MP4 or WebM: video wins decisively for photographic footage and needs no library. Lottie wins for UI motion, icons and illustration, where it is smaller, resolution independent and controllable in code.
- Against animated SVG or CSS: similar in spirit, but Lottie carries its timing model with it. An SVG animation's behaviour is spread across markup, CSS and sometimes JavaScript. A Lottie is one file a designer hands a developer.
- Against Rive: Rive is built on state machines and runtime interactivity. Lottie is a linear timeline. Different tools for different jobs.
dotLottie is the same animation, zipped
A .lottie file is a ZIP archive holding one or more animation JSONs, any binary assets they reference, and a manifest describing them. It exists because raw JSON is verbose, and because embedding images as base64 inside JSON inflates them by roughly a third.
Packing gives you a meaningfully smaller file, with the saving depending on how much of it is repeated structure and embedded imagery. It also lets several animations travel as one asset, which is handy for themed sets.
Support is good but not universal. Modern web runtimes read it and older integrations sometimes expect raw JSON. Ship JSON to a third party embed, dotLottie to your own app.
Why the same file looks different on Android
On the web, lottie-web is the original player, rendering to SVG, Canvas or HTML. dotlottie-web is the newer WebAssembly player built on the same rendering core the native runtimes use. On iOS and Android, lottie-ios and lottie-android draw natively.
These do not produce identical output. Support for expressions, mattes, merge paths and certain effects varies between them, and even the SVG and Canvas renderers inside lottie-web disagree about filters and blur regions.
So test in the runtime that will ship. A file that looks perfect in a web preview can render wrong on Android, and it is nearly always an unsupported feature rather than a corrupt file.
What makes a Lottie heavy
Three things dominate file size and none of them is how long the animation runs.
Embedded raster images come first. A base64 PNG inside the JSON can outweigh everything else in the file, and it also throws away the resolution independence you picked the format for. Path complexity comes second, because a traced illustration carries every one of its thousands of points. Over-keyframing is third, and that is what you get when a source animation was baked frame by frame instead of exported with real interpolation.
Optimising a Lottie is mostly attacking those three. Extract the images, simplify paths at the source, avoid baked keyframes.
When not to use it
Lottie is a poor fit for photographic content, for heavy raster texture, and for long form motion where a video codec, which only stores what changed between frames, beats vector redrawing on both size and CPU.
It also costs something at runtime. Every frame is drawn rather than decoded, so a very complex animation can be more expensive than the equivalent video on a cheap phone. For UI motion this never matters. For a full screen illustrated sequence, measure it.