All insights

Lottie vs Video for Fitness AppsFile Size, Customization and Integration

An exercise preview is a small part of a fitness app. Across an entire workout library, the way those previews are produced, stored and displayed becomes a much bigger decision.

File size matters. So do visual consistency, brand colors, offline access and the ability to reuse the same exercise across different screens.

I created Vector Fitness Exercises (VFE) to bring those needs together: a ready-made library of vector exercise animations for apps, websites and wearables. The library snapshot used in this comparison contains 1,603 animation assets across Male and Female variations and nine equipment categories.

This article compares that approach with rendered video, using real VFE files and practical integration scenarios.

The question is not whether video is good or bad. It is which approach makes sense for the job.

What the actual files show

Consider Assisted Chin Up, a VFE exercise animation that includes both a character and moving gym equipment.

The following results come from the actual animation files, the original video export and additional H.264 encodes of that video:

Assisted Chin UpMeasured files · One exercise
Actual file sizes for Assisted Chin Up. Export settings and durations differ; this is not an equal-quality benchmark.
VersionFormat & playback settingsDurationFile size
Lottie JSONVector source · 24 FPS source timeline4.08 s122.2 KB
dotLottieThe same vector animation, compressed4.08 s13.5 KB
Original MP4H.264 · 914 × 1080 · 60 FPS4.08 s2.22 MB
Re-encoded MP4H.264 · 914 × 1080 · 60 FPS4.08 s150.5 KB
Smaller MP4 previewH.264 · 304 × 360 · 30 FPS4.10 s38.2 KB
MP4 thumbnailH.264 · 152 × 180 · 30 FPS4.10 s21.2 KB
GIF export914 × 1080 · 50 FPS stored timing4.90 s5.69 MB

Sample sizes use decimal units. Video compression is lossy, and the GIF has different playback timing. These are real export examples, not a controlled equal-quality benchmark. Export settings & measurement notes

The first important result is that video can be optimized substantially. The original MP4 is not a fair representation of the smallest video that could serve a preview.

The second is that the 13.5 KB dotLottie file retains the original vector animation data. Its embedded JSON is identical to the separate source file. Compression has not turned the exercise into a low-resolution thumbnail.

For online delivery, JSON can also be compressed. This example becomes approximately 12.1 KB with gzip, so the raw JSON size should not be confused with the amount necessarily transferred over the network. HTTP compression and dotLottie packaging are different ways of reducing delivery size.[1, 2]

The advantage is not that every video must be large. It is how much flexibility the compact vector version retains.

A complete exercise library
can live inside the app

The library-level measurements are approximately 91.6 MB for Lottie JSON and 15.27 MB for dotLottie, covering the 1,603 animation assets in this snapshot.

15.27MB
Approximate total · dotLottie files
The whole collection.That puts the complete compressed collection at around 15 MB of animation data.

For an offline-first fitness app, that changes the options. Instead of requesting each exercise preview during a workout, the app can include the licensed files and a compatible player, then load the animations locally. Loading animations from an app bundle is an established Lottie workflow.[3]

Files already on the device require no animation bandwidth during local playback.

This can be useful for workouts with unreliable connectivity, compact wearable experiences or products that want exercise previews available immediately after installation.

Video can also be stored locally or cached. Offline playback is not exclusive to Lottie. The practical advantage here is the small size of the complete VFE collection, not a special billing rule. Initial distribution, updates, the player and the rest of the application remain separate from the animation-data total.[4, 5]

VFE provides downloadable assets, not an animation-hosting or playback API. Teams can bundle the files, host them on their own server or CDN, or combine local storage with downloads as needed.

Match the brand without
remaking the animation

A technically suitable exercise library still needs to fit the product visually.

With VFE, clothing, skin, hair and background colors can be adjusted through the customization tools. The Male variation also has a Simple hairstyle option. These are practical customization features of the library, not a requirement to manually redesign every exercise.

For Lottie playback, changing the palette does not require rendering a new video.

A red-and-graphite exercise can become a muted green version for another interface while retaining the same movement. The live library makes it possible to explore those choices before integration.

In a rendered video, the character’s appearance is already encoded into the frames. Changing specific clothing or skin colors generally means editing and producing another video version. With VFE’s vector source, those colors remain editable properties.[6]

The aim is simple: the exercise should look like part of the interface, not an unrelated clip placed inside it.

One source for different screen sizes and refresh rates

Different sizes, without separate resolution exports

An exercise may appear as a small item in a workout list, a larger demonstration during a session and a compact preview on a wearable.

VFE’s vector shapes can be redrawn at those different sizes from the same animation file. Making the display larger does not require adding more pixels to the stored asset.[6]

Video can also be displayed at different sizes, and existing footage can be transcoded into smaller versions without reopening the original animation project. But a smaller video export has a fixed raster resolution. Enlarging it later does not recover detail that was removed.[7]

With a vector source, display size does not have to become another export decision.

Different refresh rates, without a separate high-FPS video

The Assisted Chin Up source used above has a 24 FPS timeline. That does not mean a compatible Lottie player must display only 24 distinct updates per second.

With frame interpolation enabled, the player can calculate intermediate values between keyframes. In lottie-web, this allows updates on each browser animation frame, which generally follows the display’s refresh rate. The same source can therefore provide intermediate motion on higher-refresh displays without a separate 60- or 120-FPS export.[8, 9]

This is a capability, not a guarantee of 120 FPS on every device. Actual smoothness still depends on the animation, player and available processing power.

The file can stay the same while the way it is displayed changes.

Motion that fits the workout interface

VFE animations are intended for short, repeatable exercise demonstrations. A continuous exercise loop can remain on screen for as long as the interface needs it.

A compatible Lottie player can pause at a particular point, change speed, play a selected segment or coordinate playback with interface events. That gives a team options beyond starting an entire clip from the beginning each time.[8]

Video also supports looping, seeking and playback-speed controls. Those features are not unique to Lottie. The difference is that VFE combines controllable playback with editable vector content and an exercise library built around consistent demonstrations.[4]

A workout builder might show small looping previews. A session screen might display one larger exercise. A detail view might pause the movement while explanatory text is visible.

These are different uses of the same asset, rather than separate pieces of media that must all be produced independently.

Assisted Chin UpLottie JSON
Male · Gym MachinesVECTOR / LOOP

One source.
Different playback.

Pause the movement or change its speed. The same JSON file stays loaded throughout; changing playback does not request another animation.

Playback speed changes the duration of the movement. It is separate from display refresh rate.

The production advantage:
the library already exists

Choosing a format does not create the content.

Even after deciding on video or animation, a team still needs the exercises, a consistent style, usable organization and a way to adapt the collection to the product.

VFE addresses that work with an existing library organized by variation, equipment and major muscle groups. The nine categories cover Bodyweight, Dumbbells, Barbell, Cable Machine, Gym Machines, Resistance Bands, TRX, Stretching and Foam Roller. Male and Female are separate collections with substantial overlap, rather than an assumption that every exercise exists identically in both.

This lets a team start by evaluating suitable exercises instead of planning an entire production pipeline.

It also avoids an all-or-nothing purchase. Individual Animations, Equipment Packs, Single Variation and Full Library provide different starting points. Eligible earlier payments can count toward broader coverage or a higher license tier through the Fair Upgrade Policy (FUP). Update coverage follows the purchased scope.

The value is both technical and practical: compact animation data, with the exercise-production work already done.

Keep the vector source,
use the output that fits

Purchases are delivered as Lottie JSON through the Download Center. VFE Tools can be used for customization and supported exports, including dotLottie, MP4 and transparent WebM. Other permitted conversion workflows can also be used.

That means choosing VFE does not require using a Lottie player in every part of the product.

A team might use dotLottie for an offline exercise catalog, JSON in a customizable web interface and rendered video where the existing workflow expects video.

The important distinction is that the editable vector source remains available. A particular video export becomes an output of that source, rather than the only representation of the exercise.

Where video remains
the better choice

When the purpose is to show a real coach, spoken guidance, detailed technique or the subtleties of a person’s movement, video is often the more appropriate medium.

A stylized exercise preview and an instructional recording are not interchangeable. They can serve different parts of the same experience.

Animation for
quick recognition.

Compact, repeatable exercise previews within the interface.

Video for
detailed explanation.

Real people, spoken guidance and technique demonstrations.

Video may also be the simpler integration choice when a product already has a mature video pipeline and needs only a small number of fixed previews. The compact MP4 examples above show why that option should not be dismissed.

The useful comparison is not “vector good, video bad.” It is whether the product benefits from a reusable, customizable exercise collection, or primarily needs finished footage.

Small files still need
a suitable implementation

File size measures storage and transfer, not everything that happens during playback.

A Lottie player must interpret and render the animation. Complexity, simultaneous animations and renderer choice affect performance. Video decoding has its own trade-offs and may benefit from efficient platform support. Neither file size alone nor format choice proves lower battery consumption or memory use.[8, 10]

The sensible check is to test representative exercises on the actual target devices, including the intended number of simultaneous previews.

VFE’s sample page provides files for that evaluation, with color and character options available before purchase.

Final thought

For a fitness product, the strongest argument for VFE is not a single file-size ratio.

It is the combination: a compact library, a consistent visual style, editable colors, scalable graphics, controllable motion and a practical route to offline playback.

Video remains valuable where realism and detailed instruction matter. VFE provides a different foundation for the recurring exercise previews that appear throughout an interface.

Keep the source flexible. Keep the previews lightweight. Use video where video adds something the animation cannot.
Measurement notes & technical sources

Sample files

Assisted Chin Up sample inspected on 7 October 2026. Exact original sizes: JSON 122,211 bytes; dotLottie 13,472 bytes; MP4 2,217,173 bytes; GIF 5,687,619 bytes. Sample units are decimal: 1 KB = 1,000 bytes and 1 MB = 1,000,000 bytes. Table values are rounded.

The JSON source contains a 1100 × 1300 composition, a 24 FPS timeline and 98 frames (approximately 4.083 seconds). It has 47 top-level layers and no embedded image assets. These are source coordinates and timeline properties, not a fixed raster output. The JSON inside the dotLottie package is byte-for-byte identical to the submitted source.

Video and GIF settings

The original MP4 is H.264 / AVC High, 914 × 1080 pixels, 60 FPS, 245 frames, 8-bit YUV 4:2:0, no audio. Its video-stream bitrate is approximately 4.34 Mbps. The three additional MP4 files are lossy re-encodes of that MP4 using FFmpeg 7.1.5, libx264, CRF 23, the medium preset, YUV 4:2:0 and faststart, without audio. They are not identical-quality copies or claims of the smallest possible video. Their exact sizes are 150,485, 38,159 and 21,180 bytes. Rounding to a 30-FPS frame grid gives the smaller variants a duration of 4.10 seconds.

The GIF contains 245 frames at 914 × 1080 pixels, each storing a 20 ms delay: 50 FPS nominal timing, 4.90 seconds, infinite loop, with a 256-entry global color table. Its duration differs from the JSON and MP4. These are measurements of specific exports, not a controlled equal-quality benchmark or a universal ranking of format efficiency.

Compression and collection totals

The gzip example uses level 9 compression of the supplied JSON: 12,080 bytes. This is a compression test, not a measurement of the production website’s actual transferred payload. Server settings, headers and caching affect real network delivery.

The collection figures (1,603 assets, approximately 91.6 MB JSON and 15.27 MB dotLottie) are VFE’s reported library-snapshot totals, not a whole-library recount from the one-exercise sample. They refer to animation files, not a complete application, player or runtime memory. Library totals are approximate and should not be used to derive a more precise average from this article.

The live preview applies VFE’s red-and-graphite palette and the Male Simple hairstyle at display time. Sample sizes in the table describe the unmodified submitted files. No CPU, battery, memory or device-frame-rate benchmark is claimed.

Technical sources

  1. [1] MDN: HTTP compression
  2. [2] dotLottie: compressed animation packages
  3. [3] Airbnb: Lottie and local app-bundle loading
  4. [4] MDN: video playback, seeking and controls
  5. [5] MDN: HTTP caching
  6. [6] Lottie specification: vector shapes, properties and timing
  7. [7] FFmpeg: transcoding existing media
  8. [8] lottie-web: playback control and subframe interpolation
  9. [9] MDN: animation frames and display refresh rate
  10. [10] MDN: media smoothness and power-efficiency capabilities