Four formats, two fundamentally different ideas
The comparison makes sense only once you see that these are not four variations of one thing. They split into instructions and pixels.
Lottie (and its packaged form, dotLottie) is instructions. A JSON file describes shapes, paths, colours, and how they change over time; a player library reconstructs the picture at runtime by drawing vectors. Rive belongs to the same family with a richer runtime (state machines, input-driven blending). Because the file contains a description rather than a picture, it is small, scales to any size, and can be changed by code (recolour a shape, respond to a tap).
GIF, transparent video (WebM, HEVC, ProRes), and sprite sheets are pixels. Somewhere a renderer produced actual frames, and the file stores them: GIF as a palette-limited image sequence, video as a compressed stream, a sprite sheet as one large image the code crops through frame by frame. Pixel formats can show anything that can be rendered (fur, lighting, painterly texture, 3D) but only at the resolution they were made, and they cannot be changed without re-rendering.
This split is the source of nearly every real difference below, and it is why the winning question is about the artwork, not the platform.
The comparison matrix
| Axis | Lottie / dotLottie | Transparent video | GIF | Sprite sheet |
|---|---|---|---|---|
| What it can depict | Flat vector shapes; gradients; limited raster layers | Anything renderable: 3D, painterly, fur, light | Anything, at 256 colours per frame | Anything, at fixed frame count |
| Typical file size, 6 s character | 15–150 KB (simple) to 1 MB+ (complex) | 0.5–2.5 MB (VP9 alpha, 720 px) | 3–8 MB (480 px) | 2–6 MB (PNG, 24 fps) or fewer frames |
| Resolution | Infinite; crisp at any size | Fixed; softens when upscaled | Fixed; pixelates when upscaled | Fixed |
| Transparency | Full 8-bit, native | Full 8-bit (WebM/HEVC/ProRes) | 1-bit, hard edges | Full 8-bit (PNG) |
| Interactivity | High: segments, state machines, dynamic colours | Low: play, pause, seek | None | Medium: code chooses frames |
| CPU / GPU cost | CPU-bound; complex files can be expensive, especially many at once | Hardware video decode where available; cheap per pixel | Cheap but memory-heavy for long loops | GPU-friendly in canvas/WebGL; memory-heavy |
| Runtime dependency | Player library (60–300 KB JS, or native SDK) | None on the web; native player on mobile | None | Your own code or a game engine |
| Production workflow | After Effects + Bodymovin, or Lottie/Rive editors; designer time per animation | Any renderer; AI generation; export once | Convert from video | Render frames, pack with a tool |
| Edit after the fact | Yes, by code or in the editor | No; re-render | No | No |
| Where it cannot go | Email, chat, docs, slides | Email, most chat, some docs; Safari needs a second file | Nowhere; it goes everywhere | Anywhere without custom code |
A few rows deserve commentary. The file size row is the one people quote in arguments, and it is misleading in isolation: a 40 KB Lottie of a complex character can cost more CPU per second than a 1.5 MB video, because the video is decoded by dedicated hardware while the Lottie is rasterised by the main thread. On a mid-range Android phone with three Lottie animations on one screen, that shows up as dropped frames and a warm device. Size is what you download once; rendering cost is what you pay every frame.
The what it can depict row is the one that actually decides. If the character was rendered (a soft 3D mascot, a painterly illustration, anything with shading that is not a simple gradient), there is no Lottie version of it. Lottie is not a compression format for video; it is a different art form, and getting a rendered character into it means redrawing the character as vectors, by hand, and then animating the vectors, by hand.
The question that settles most of these debates
Is the character drawn with vectors, or rendered?
If it is vectors (a flat illustration system, geometric shapes, the kind of mascot a brand team builds in Figma or Illustrator), Lottie or Rive is a strong default for in-product UI: tiny files, sharp at every density, recolourable for themes, and able to react to input. The cost is production: someone has to build each animation in After Effects or a Rive editor, and each new state is designer time. That is a fine trade for a small number of high-value animations.
If it is rendered (soft 3D, textured, anime-shaded with real lighting, a photo-derived avatar), video is not one option among several; it is the option. The alternatives are GIF (same pixels, worse in every way except portability) and sprite sheets (same pixels, more memory, more code). The trade is the opposite of Lottie’s: production is fast and cheap, and you give up interactivity and scalability.
Once the answer is known, the remaining choices are small:
- Vector character, web or native app, few states → Lottie (dotLottie if you want several animations in one file). Rive if the states need to blend or respond continuously to input.
- Vector character, but the destination is email, docs, chat, or slides → GIF. Nothing else is accepted.
- Rendered character, web → transparent WebM in a
<video>, with a Safari strategy. The embedding guide has the markup and the performance rules. - Rendered character, native iOS → HEVC with alpha in
AVPlayer(or a UIKit/SwiftUI video layer). Convert from the ProRes MOV on a Mac. - Rendered character, native Android → VP9 alpha plays in a WebView; native
ExoPlayersupport for alpha is inconsistent across devices, so many teams use a WebView, a sprite sheet, or a Lottie with embedded raster frames for short loops. - Rendered character, game engine or canvas → sprite sheet or PNG sequence; you control frame timing and can blend states in code.
- Rendered character, anything else → GIF.
Hybrid strategies that mature teams settle on
In practice most products end up with two formats, split by role rather than by platform:
- Video for the character, Lottie for the chrome. The mascot (rendered, expressive, changes rarely) ships as transparent video; the checkmarks, loaders, confetti, and toggles (vector, tiny, need to match theme colours) ship as Lottie. The two coexist on the same screen without conflict.
- Video in marketing, Lottie in product. The website hero and the app store preview want the richest version of the character; the in-app empty state, shown thousands of times, wants the cheapest render path. Some teams keep a simplified flat variant of the mascot for the second role. The app mascot guide has more on which moments deserve which weight.
- Video as master, GIF as ambassador. One rendered source; the GIF derived from it goes into release notes, support replies, social posts, and slide decks, where nobody will run a Lottie player.
What rarely works is the reverse: trying to make a Lottie do a rendered character’s job by embedding raster image layers in it. You get the file size of a sprite sheet, the CPU cost of Lottie, and the interactivity of neither.
Production cost is part of the format
Format comparisons usually stop at runtime characteristics. For a small team, the production pipeline matters more, because it decides how many animations you will actually make.
- Lottie: each animation is a design task, typically hours of After Effects or Rive work per state by someone who knows the tool. Five states is a real project. Changing the character afterwards means revisiting every file.
- Transparent video from a traditional pipeline: illustration, rigging or frame-by-frame animation, rendering with alpha. Days per state, and the same change-cost problem.
- Transparent video from an AI studio: minutes per state once the design is approved; a new state is a motion prompt. The character is locked at design approval, so consistency is automatic. The trade is less frame-level control: you direct the motion rather than keyframe it.
- GIF and sprite sheets: conversions of one of the above; cost is essentially the source’s cost plus a few minutes.
The practical effect is that teams using video from a generative pipeline tend to have more states than teams using Lottie, simply because the marginal state is cheap. Whether that is good depends on discipline; a character with twenty states used tastefully is a delight, and one used indiscriminately is noise. The cost comparison puts numbers on the three production routes.
A short review checklist
Before the format is locked in, the team should be able to answer these without hesitation:
- Is the artwork vector or rendered? (Decides the family.)
- Does any animation need to respond to input beyond play and pause? (If yes and vector: Lottie or Rive.)
- How many will be on screen at once on the slowest supported device? (Video scales better than multiple Lotties.)
- Does it need to appear anywhere HTML and players do not run? (If yes: a GIF derivative is required regardless.)
- Who will make the next ten animations, and how long will each take? (The honest answer often decides the format.)
- What happens when the character design changes? (Re-render ten videos, or re-edit ten Lottie files?)
If the answers point to video and you need a character to test with, every new studio account includes enough free credits for one design and its first animation; the exports arrive as WebM, MOV, GIF, and MP4 together, so the same clip can be evaluated in every destination on this page. The features page lists the exact export specifications.