Both Lottie and Rive are vector animation formats that run in a browser or native app without GIF's quality loss. But they have fundamentally different architectures — and the performance implications are real.

This post covers file size, CPU usage, rendering overhead, and the decision framework for choosing between them.

What each format actually is

Lottie is a JSON file that describes vector shapes, transforms, and keyframes exported from After Effects (or similar tools). The runtime replays those keyframes on a canvas or SVG element. It's essentially a recorded animation.

Rive is a binary .riv file that contains an artboard, animations, and a state machine. The state machine defines states (idle, hover, loading, success) and the transitions between them. Instead of replaying keyframes, the runtime responds to inputs and drives transitions programmatically.

The architectural difference: Lottie = playback. Rive = interactive runtime.

File size

For comparable icon-scale animations (32×32px, 1-2 second loop):

Format	Typical size	Notes
Lottie JSON	15–80KB	Text format — compressible. Larger if many keyframes or complex paths
Rive `.riv`	5–20KB	Binary format — inherently compact. State machines add minimal overhead
GIF	50–200KB	Raster — no compression advantage. Gets large at any decent resolution
WebM (VP9)	10–40KB	Good compression but fixed playback, no interactivity

Rive files are typically 3-5× smaller than equivalent Lottie JSON. This matters at scale: if you have 30 icons on a page, that's 2.4MB vs 600KB transferred before gzip.

After gzip, the gap narrows (JSON compresses well), but Rive still wins:

Lottie 40KB JSON → ~8-12KB gzipped
Rive 12KB binary → ~8-10KB gzipped (already compact, less compression gain)

Verdict: Rive smaller, especially pre-gzip. Matters for mobile and first-load performance.

CPU and rendering overhead

Lottie renders by replaying every keyframe at the animation's frame rate (typically 24-60fps). Even when nothing on screen changes, the JavaScript ticker is running. Each Lottie instance creates a requestAnimationFrame loop.

Rive's runtime is more efficient:

Written in C++, compiled to WebAssembly for web
Renders only what changes (dirty-rect optimization)
State machine can sit idle with zero CPU when no state change is occurring
Single shared runtime instance — multiple Rive components share one WASM module

Practical impact: with 5+ simultaneous Lottie animations, CPU usage spikes noticeably on mobile — each instance runs its own requestAnimationFrame loop regardless of whether anything visually changes. Rive handles many concurrent animations more gracefully because the WASM runtime batches rendering across shared instances and skips work when nothing is dirty.

The gap widens with animation count. At 1 animation the difference is marginal — both formats are cheap. At 20+ simultaneous animations, Lottie's per-instance ticker overhead compounds linearly while Rive's shared-runtime, dirty-rect model keeps overhead close to flat. If you want exact numbers for your own use case, profile it in Chrome DevTools' Performance tab on a representative device — CPU cost depends heavily on animation complexity (path count, layer count) and the device's GPU, so generic percentages don't transfer reliably between projects.

Rive's idle state approaches 0% CPU because the state machine can pause when no inputs are changing — there's no keyframe ticker to keep running while nothing is happening.

Initial load / bundle overhead

Lottie-react (the most popular React package):

Bundle: ~52KB gzipped
Loads JSON file at runtime
No WASM dependency

Rive React (@rive-app/react-canvas):

Bundle: ~28KB gzipped for JS
Plus ~250KB WASM file (loaded once, shared across all Rive components, cached aggressively)
First load: heavier. Second load: cached

For a page with 1-2 icons: Lottie wins on initial load (no WASM). For a page with 10+ icons or a full app: Rive wins (WASM amortized, runtime more efficient).

The crossover point is roughly 3-5 Rive icons on a page — above that, the WASM overhead is paid once while the per-icon size savings compound.

Frame rate

Both formats support 24-60fps animations. Lottie's frame rate is baked into the JSON (exported from After Effects). Rive's animations also have baked frame rates but the state machine transitions can be smoother because they interpolate between states programmatically rather than replaying fixed keyframes.

For icon-scale animations (30-60 frames of a simple shape), frame rate is rarely a bottleneck — both formats feel equivalent at 60fps.

Memory usage

Lottie creates a canvas element per animation. Each one allocates GPU memory.

Rive's renderer shares a single canvas context across all instances by default. This is why 20+ Rive icons use dramatically less GPU memory than 20+ Lottie icons.

On mobile Safari (which has a 75MB GPU memory limit for a single page), this matters. A page with 30 Lottie icons can trigger GPU memory pressure; 30 Rive icons typically won't.

Interactivity overhead

This is where Rive's architecture shines. Hover, click, and scroll-triggered animations in Lottie require external JavaScript to manage playback state:

jscopy
// Lottie: manual play/pause/seek management
const ref = useLottieRef();
const handleHover = () => ref.current?.play();
const handleLeave = () => ref.current?.stop();

Rive state machines handle this natively — you set a boolean input and the runtime handles the transition, easing, and return animation:

jscopy
// Rive: state machine handles everything
hoverInput?.change(true);  // runtime does the rest

For complex interactions (multi-state loading spinners, toggle icons, progress indicators), Rive's model is dramatically simpler to implement and more robust to edge cases.

When to use each

Use Lottie when:

You're importing from After Effects and want no rework
You have 1-3 non-interactive decorative animations
You can't afford the WASM first-load cost
Your team already produces .aep files

Use Rive when:

You need interactive animations (hover, tap, drag, scroll-linked)
You have 5+ animated icons on a page
You're building a mobile app (iOS, Android, Flutter) — Rive's native runtimes outperform Lottie's on mobile
You care about idle CPU (e.g., battery life on mobile)
You want consistent 6-format exports from a single source file

The practical rule: for a production product UI, use Rive. For one-off decorative animations where you're working from an After Effects workflow, use Lottie.

All Unicorn Icons ship both formats — download Lottie JSON for simpler cases, Rive for interactive.

Browse icons → · Rive vs Lottie deep-dive → · How to use Lottie in React → · Rive React tutorial →

Lottie vs Rive: File Size, Performance & Which to Use in 2026