Lottie Optimizer

Why Lottie exports are bigger than they need to be

Export tools optimize for correctness, not size. Bodymovin writes every coordinate with full floating-point precision — 128.48000000000002 where 128.48 renders identically. Every layer keeps its authoring name ("Shape Layer 47 copy 3"), every group its match name, and the file carries generator metadata no player reads. On a complex animation these overheads are thousands of occurrences; trimming them routinely removes a third of the file before touching anything visual.

Embedded images: the biggest lever

Animations converted from raster sources — like the output of our GIF to Lottie and MP4 to Lottie converters, or After Effects comps with image layers — embed their frames as base64 images. Those images usually dominate the file size. Re-encoding PNG frames as WebP at 80% quality halves them with no visible change, and downscaling a 1080px-wide embedded image that displays at 400px reclaims even more. The optimizer only keeps a recompressed image if it's actually smaller, so it can never make your file bigger.

What's safe to strip — and what isn't

Lottie players ignore nm (names), mn (match names), and meta during playback, so stripping them is free — unless your code manipulates the animation by layer name at runtime (dynamic text swaps, theme color replacement). In that case, uncheck "Strip layer names." Hidden layers (hd: true) never render and are pure dead weight from the authoring file — removing them is always safe. Numeric precision at 2 decimals is sub-pixel accurate; drop to 1 decimal only for large animations where a hundredth of a pixel truly cannot matter.

Page speed, app bundles, and when size matters most

A hero animation that loads with your landing page sits directly in the critical path — Core Web Vitals feel every extra 100KB. Mobile apps pay twice: bundle download size and memory at parse time. Optimizing before shipping is the single highest-leverage step, and it composes with delivery tricks like gzip (which your server applies on top). After optimizing, verify the result in the preview, then round-trip it through our Lottie to GIF or Lottie to MP4 converters if you also need shareable preview files.

Optimizer vs. gzip: why you need both

It's a common assumption that server-side gzip or Brotli compression already handles this — it doesn't, because it solves a different problem. Gzip compresses bytes in transit over the network; the browser still has to fully decompress and JSON.parse the entire file before lottie-web can render a single frame. A 2MB Lottie gzips down for the wire, but still costs 2MB of parse time and memory once it arrives. This optimizer shrinks the actual object — fewer bytes to parse, less memory held during playback — and stacks on top of whatever transport compression your server already applies. Use both together for the smallest real-world footprint.

Optimizing files from any source, including LottieFiles

This tool doesn't care where your Lottie came from — a download from the LottieFiles marketplace, a Bodymovin export from After Effects, or the output of our own GIF to Lottie and MP4 to Lottie converters all optimize the same way. Both .json and .lottie (dotLottie) files are accepted directly — no manual unzipping required for dotLottie archives.

Reading the before/after comparison

After optimizing, the result panel shows original size, optimized size, and percentage saved side by side, plus a live preview rendered from the optimized JSON — not the original — so what you see is exactly what you'd ship. If a file shows 0% savings, it's usually because it was already hand-optimized or is pure vector with no embedded images; try lowering the image quality slider or precision setting further, though at some point a small, well-authored vector Lottie simply has little left to trim.

Common problems and fixes

Optimized animation looks different from the original: check the preview carefully — if an expression-driven effect broke, the tool should have auto-detected and kept layer names, but re-run with "Strip layer names" unchecked to be safe. Savings are smaller than expected: the file likely has few or no embedded images — precision and metadata trimming alone typically save 20-40%, not 60%+, on pure vector animations. File won't upload: confirm it's under 30MB and a valid .json or .lottie — corrupted or partial exports will fail to parse. Everything runs client-side — no uploads, no accounts. See our full Lottie converter toolkit for every conversion direction in one place.