Animations on the internet, and especially micro-animations, are more than just visual decoration. They are often the finishing touch in professional web solutions. When used correctly, they can genuinely contribute to the user experience. Think of subtle visual feedback that makes an interface more pleasant and easier to understand. Often underestimated, often not consciously noticed, but definitely valuable. And this is exactly where a technique like Lottie comes into play.
What is Lottie, actually?
If you work with animations, you will inevitably come across Lottie. It is often delivered by designers as a .json or .lottie file, and the idea is simple: a lightweight, scalable animation that you can use on the web, mobile, and apps without heavy videos or GIFs.
Technically, Lottie is a JSON-based format in which vector shapes, keyframes, timing, and easing are stored. It resembles SVG a bit, but it is not SVG. It is more like a description of an animation, similar to how After Effects works internally. This is no coincidence, as Lottie is usually exported from Adobe After Effects via a plugin.
How it works on the web
An important detail is that Lottie is not natively supported by browsers. You cannot simply drop it into an img tag like a PNG or SVG. To play a Lottie animation, you need a JavaScript player, usually lottie-web.
In practice, this means you load a script and place a container element on your page where the animation is rendered. That rendering often happens as SVG or canvas, depending on the settings. Without that player, nothing happens.
This makes Lottie fundamentally different from SVG or video. It is not a file that “just works”, it is a format that requires a runtime. For the true enthusiasts, it is somewhat reminiscent of Macromedia Flash from the past. Later taken over by Adobe. And now completely gone because it was quite unsafe. After Flash, there was never really a proper HTML5 alternative with an IDE for designers.
File formats and why it sometimes looks “binary”
There are multiple variants of Lottie files. The most well-known is a plain JSON file, which is human-readable. But there are also .lottie files, which are essentially compressed archives, similar to a zip file. If you open such a file in a text editor, it may look binary or encoded. But if you add the .zip extension to a .lottie file, you can extract it. Then you will see the raw JSON and asset files.
This is not encryption or protection of the design. It is purely packaging and compression. Unlike compiled code, it is not intended to prevent reverse engineering.
Control over the animation
One of Lottie’s strengths is that you have control over the animation via JavaScript. You can start, stop, loop, jump to a specific frame, and attach events. That makes it more interesting than video, where you have less granular control.
At the same time, this also means you depend on JavaScript. You cannot simply adjust a hover animation with CSS like you would with SVG. Everything runs through the player API.
How big and “lightweight” is it really?
Lottie is often presented as a lightweight alternative to GIFs and video. That is partly true, but the full picture matters. An animation file can indeed be small, for example a few kilobytes of JSON, but you also need to account for the JavaScript player.
The lottie-web library is roughly tens of kilobytes, depending on minification and compression. In today’s context, that is still quite manageable. But in many cases, you are still adding an extra payload that you would not need with, for example, pure SVG or a simple CSS animation.
Compatibility and “does it work everywhere?”
This is an area where developers need to be cautious. Lottie works well in modern browsers and in apps where the right libraries can be used. But it is not universal in the way video formats or other web standards are.
If an environment does not support JavaScript, or has a limited runtime, then it stops there. Think of certain embedded systems, older devices, or minimalist browsers. In that sense, a simple MP4 is still much more robust.
If something truly needs to work everywhere, without dependencies, then video or a static fallback remains the safest choice.
Vendor lock-in and workflow
Formally, Lottie is an open format and the players are open source. However, there is still a form of lock-in in the workflow. Most animations are created in After Effects and exported via specific plugins. Not all After Effects features are supported, so you are also limited by what the export can handle.
This means developers become dependent on how designers deliver their work, and designers become dependent on a specific toolchain. It is not a hard lock-in, but it is a practical dependency.
Comparison with alternatives
When you compare it with other techniques, clear differences emerge. SVG with CSS or JavaScript is fully native in the browser, requires no runtime, and gives you direct control via web standards. For simple animations, that is often the better choice.
Video, such as MP4, is extremely compatible and efficient for complex visuals. It lacks interactivity, but works almost everywhere without extra code.
Lottie sits in between. It offers more control than video and can handle more complex animations than pure CSS, but it requires an additional layer and introduces dependencies.
When is Lottie a good choice?
Lottie is interesting for micro-animations in interfaces, such as icons, loaders, and small visual feedback. It can also work well in mobile apps, where native libraries are available and performance is predictable.
For marketing visuals, it can be a better alternative to GIFs because it is sharper and often smaller. Still, it feels like it is just shy of being the powerful open web solution we could really use in HTML5.
When should you avoid it?
If compatibility is critical, or if you want to work without JavaScript, then Lottie is not a good choice. It is also overkill for simple animations. In those cases, SVG or CSS is usually better. It sits somewhere between animated SVG and MP4.
For core content, SEO-relevant elements, or anything that must be robust across all devices, it is wise to have a fallback or choose another technique. But with a static fallback included, it is perfectly fine for micro-animations. With each additional micro-animation, the impact of the JavaScript runtime is also softened because the overhead is spread across multiple animations.
Concluding
Lottie is interesting, but not a miracle solution. It solves a specific problem: efficiently displaying complex vector animations with control, but it also introduces a runtime, extra weight, and dependency on tooling.
It does not feel like a new web standard, but rather like a bridge between design tools and development. That can be useful, but it is important to stay critical and not automatically choose whatever the tooling provides.
As a developer, it is wise to understand Lottie and be able to use it, but also to keep alternatives ready. The web has become strong because of open standards, and anything that deviates from that deserves a healthy dose of skepticism.