# Figma Motion to Lottie _September 1, 2026 · 11 min read · by Systergon_ > What actually happens in the conversion. Which properties cross over untouched, which are left behind and why, why the position track ends up with far more keyframes than you drew, and how to tell whether the result is faithful before you hand it over. **Answers the question:** figma motion to lottie **What this page is for:** Explains the fidelity of converting a Figma Motion animation to Lottie — which transform properties carry over, which canvas effects are dropped, why position keyframes are baked, and how to verify the result. URL: https://systergon.com/figma-motion-to-lottie Plugin: Motion Path for Figma — https://systergon.com/products/figma-plugins/motion-path Install: https://www.figma.com/community/plugin/1654530170219655744 --- [Install Motion Path — it’s free →](https://www.figma.com/community/plugin/1654530170219655744) [See the product page](https://systergon.com/products/figma-plugins/motion-path) **The short answer:** converting Figma Motion to Lottie is lossless for anything riding the layer **transform** — position, rotation, scale, opacity, and the easing that drives them — and impossible for anything living in the artwork or on the canvas, which means colour shift, motion blur, motion trail, squash & stretch and anticipation. [Motion Path](https://systergon.com/products/figma-plugins/motion-path) names whichever of those applied to your animation in the notes under the export rather than dropping them quietly. This page is about that boundary: where it falls, why it falls there, why your position track ends up with far more keyframes than you drew, and how to check the result before anyone builds against it. If you just want the clicks, [the step-by-step guide](https://systergon.com/figma-motion-export-to-lottie) is the page you want. ## Where the conversion happens For orientation, since the rest of this page discusses the output. The conversion runs when you select the **Lottie** tab under **… → Copy as code** — and only then, because it bakes far denser keyframes than the CSS and SVG snippets beside it. ![The Motion Path panel with the overflow menu open, listing Save as preset, Copy as code, Export video, Config JSON, Settings and Help](https://systergon.com/motion-guides/shots/menu-open.png) ![A step-by-step loop: the Animate tab ready to apply, the overflow menu opening to reveal Copy as code, the panel showing CSS by default, and the Lottie tab selected with the generated JSON](https://systergon.com/motion-guides/shots/steps-lottie.gif) What comes out is a small, plain document — and its plainness is what the rest of this page is really about, because it is both the source of the fidelity and the source of the limits. ![The exported Lottie JSON annotated: v the schema version, fr the frame rate, ip and op the in and out points, w and h the composition box, and ks the layer transform holding position, rotation, opacity and scale tracks](https://systergon.com/motion-guides/diagrams/lottie-anatomy.svg) ## The boundary, and why it is where it is ![Two lists: carried into Lottie are position along the path, rotation, opacity ramp, scale ramp, easing and speed profile, and arc-length travel; left behind are colour shift, motion blur, motion trail, squash and stretch, anticipation and overshoot, and loop count](https://systergon.com/motion-guides/diagrams/what-survives.svg) The rule is one sentence: **the motion rides the layer transform, so whatever is on the transform crosses over and whatever is not, does not**. That is not an arbitrary limit of the exporter. It follows from a design decision that makes the file far more useful than it would otherwise be. The exported Lottie contains a placeholder shape sized to your object rather than your artwork, so a developer swaps in the real asset — or parents it to the transform — and keeps every bit of the motion. One motion file can drive different artwork, and artwork can be redrawn without the animation being re-approved. The cost of that decision is exactly the second list. If the artwork is a placeholder, an effect that animates the _artwork_ has nothing to animate. ### What crosses over - **Position along the path** — the whole traversal, at the right speed, with the right timing. - **Rotation**, including rotate-to-path with auto-flip. - **Opacity ramps** — fading from a start value to an end value across the path. - **Scale ramps** — growing or shrinking across the traversal. - **Easing and the speed profile** — including slowing into corners and speeding on straights. - **Arc-length travel** — constant speed regardless of how your vertices are distributed. ### What does not, and the specific reason for each - **Colour shift** keys the object’s fill. The fill lives in your artwork, and the artwork is a placeholder in the exported file — so there is nothing to key. - **Motion blur** has no layer-blur equivalent that Lottie players support consistently. A version that rendered on one player and not another would be worse than an honest omission. - **Motion trail** bakes extra ghost copies onto the canvas rather than animating the layer. It is not a property of the moving thing; it is several more things. - **Squash & stretch** needs a per-axis scale keyed to velocity, which would fight the scale ramp already on the transform. - **Anticipation & overshoot** extends the motion beyond the path ends on the canvas timeline — outside the traversal the export describes. - **Loop count** is a category difference rather than a loss. Figma repeats the traversal on its timeline; in Lottie, looping is a player setting, so the JSON holds one clean pass. The plugin prints whichever of these applied to _your_ animation in the notes, generated from your configuration rather than as a fixed disclaimer: ![The Copy as code panel with the Lottie tab selected, showing the Lottie description, a code box beginning with version 5.9.0, and a note reading that the moving layer is a placeholder shape sized to your object](https://systergon.com/motion-guides/shots/copy-as-lottie.png) ## Why your position track has hundreds of keyframes This is the question every developer asks when they first open the file, and it looks like a defect until you know why. ![A comparison: CSS offset-path expresses a curve as two keyframes and a timing function, while Lottie samples the same curve into many unevenly spaced keyframes with the easing folded into the timing](https://systergon.com/motion-guides/diagrams/baked-keyframes.svg) CSS has `offset-path`. You can hand a browser a curve, a duration and a timing function, and it does the rest — two keyframes and an easing. That is what the CSS tab in the same panel emits. Lottie has no equivalent. There is no way in the format to say _“follow this curve, with this easing.”_ An object riding a curve cannot be two keyframes and a timing function, because the curve itself has to be described. So the path is sampled densely, and the easing is folded into _when_ each sample is reached rather than into a timing function on top. The consequence runs the opposite way to what “baked” usually implies: **your easing is preserved exactly** rather than approximated by whichever cubic-bézier came closest to it. The uneven spacing of those keyframes _is_ the easing, expressed directly. It is the same approach the plugin already uses when baking to the Figma canvas, so the Lottie and the canvas animation are not two different interpretations of your intent. ## Speed is measured in distance, not vertices ![Two curves: one sampled by vertex where points bunch together and the object crawls through the cluster, and one sampled by arc length where the spacing is even and the speed is constant](https://systergon.com/motion-guides/diagrams/arc-length.svg) A related and easily missed detail. If travel were measured by vertex — equal time between each point in the path — then a section of your vector with a dense cluster of points would make the object crawl through it, and a long straight with two points would make it sprint. The speed of the animation would depend on how you happened to draw the path, which is not a property anyone wants. Travel is measured by real arc length instead, so the object covers equal distance per unit time. Redrawing the same shape with more or fewer vertices does not change the motion. This holds in the export as well as on the canvas, because both read the same resolved polyline. ## Verifying the result A Lottie that parses is not a Lottie that plays correctly, and the difference matters most at exactly the moment it is hardest to check — after the handoff, in someone else’s build. The export was validated against a real player rather than by inspecting the JSON and deciding it looked plausible. Loaded into lottie-web, an object on a circular path holds a constant radius from the centre to within a fraction of a pixel; the facing sweeps a clean 360°; and the frame spacing is visibly uneven under an ease — which is precisely what “the easing is in the timing” should look like when you inspect it. Those are falsifiable claims, and they were tested. Do the same with your own file. Drop it into any Lottie preview tool and compare it against the plugin’s inline preview, checking three things: does it start and end where you expect, is the speed even where the path is even, and does the composition box frame the motion rather than clipping it. The comparison is fair because the preview is not a separate implementation: ![One resolved path and timing feeding three outputs: the inline preview, the native Figma keyframes, and the CSS, SVG and Lottie exports](https://systergon.com/motion-guides/diagrams/preview-fidelity.svg) ![The Motion Path preview showing a real blue rounded-square layer riding an S-curve path at its true size relative to the path](https://systergon.com/motion-guides/shots/preview-object.png) The preview draws your actual layer at its true size relative to the path, rather than a placeholder dot, so what you are judging is the real composition. Preview, canvas keyframes and exports all come from one resolved polyline and one timing model — there is nothing separate for them to drift from. ## What to do when something does not cross over You have three honest options, and the wrong move is to hand over the Lottie without mentioning the difference. **Accept it.** Often the effect was doing less work than you think. Motion blur on a two-second move at 60 fps is frequently invisible on a device; a subtle colour shift may not survive the surrounding interface anyway. Look at the animation without the effect before deciding it is essential. **Rebuild it in the player.** Colour is the clearest case: if the artwork is being swapped in by a developer anyway, tinting it over time is something the player or the surrounding code can do, often more flexibly than the design could. This is worth suggesting rather than treating as a compromise. **Send a video instead.** If the effect genuinely is the animation — a trail that _is_ the design, say — then [a rendering](https://systergon.com/figma-motion-export-video) is the more honest artefact. You lose the ability to drive it from application state, and you keep what the animation actually looks like. That is sometimes the right trade. ![A table mapping destinations to formats: Slack and slide decks to MP4, release emails to GIF, weight-sensitive web pages to WebM, app builds to Lottie, browser-owned motion to CSS, and reproducing a setup to Config JSON](https://systergon.com/motion-guides/diagrams/format-decision.svg) ## Fidelity across players A separate question from what the export carries: does the file look the same everywhere it runs? It should, and the reason is that the export deliberately keeps to the plain part of the format. The animation is transform tracks and nothing more exotic, on a schema version — 5.9 — that every maintained release of the four official players reads without a shim. Lottie’s newer and more elaborate features have uneven implementation across players, and a document that renders beautifully in lottie-web and subtly wrongly on Android is a worse outcome than a plain one that renders identically. ![A pipeline from Figma Motion through Motion Path to a Lottie 5.9 document, shipping to lottie-ios, lottie-android, React Native and lottie-web](https://systergon.com/motion-guides/diagrams/lottie-pipeline.svg) The practical implication is that you should not need to ask which Lottie version a team is on before sending them a file. ## The thing that changes most after handoff Worth flagging because it is not a fidelity problem and gets reported as one. When the placeholder shape is replaced by real artwork, the motion is mathematically unchanged — and it can still look different. A heavier or larger asset reads as slower at identical timing. An asset whose visual centre sits away from its bounding-box centre can look like it is drifting off the path when the transform is exactly right. Neither is the export being wrong; both are reasons to review the swapped version rather than the exported file before signing anything off. [Which point of your object follows the path](https://systergon.com/motion-path/help/anchor-point) covers the anchor control, which is usually the fix for the second one. ## Frequently asked questions ### Is converting Figma Motion to Lottie lossless? For anything on the layer transform — position, rotation, scale, opacity, easing — yes, and the easing is preserved exactly rather than approximated. For effects that live in the artwork or on the canvas, no; those cannot be represented and the plugin names them in the notes. ### Why does my Lottie have so many more keyframes than my Figma animation? Because Lottie has no `offset-path` equivalent, so a curve must be described point by point rather than as two keyframes and a timing function. The easing then lives in the spacing of those points, which is why they are unevenly distributed. ### Does the easing survive the conversion? Exactly, rather than approximately. Because the path is sampled and the easing is folded into the timing of each sample, there is no fitting step where a curve gets replaced by the nearest available one. ### Will the exported animation run at the same speed? Yes. Travel is measured by real arc length in both the canvas animation and the export, so the object covers equal distance per unit time regardless of how the vertices in your path are distributed. ### Why does my animation look slower after the developer swapped in the artwork? The timing has not changed. Larger and visually heavier assets read as slower at identical durations. Review the swapped version rather than the export, and shorten the duration if it needs it. ### Can I get motion blur into Lottie some other way? Not reliably. Lottie has no layer-blur equivalent that players implement consistently, so anything that appeared to work would be a per-player gamble. If the blur is essential to the design, export a video. ### How do I check the file is correct? Load it into a Lottie player and compare it against the plugin’s inline preview. Check that it starts and ends where you expect, that the speed is even where the path is even, and that the composition box frames the motion without clipping. ### Does it look the same on iOS, Android and the web? It should. The export sticks to transform tracks on schema 5.9, which all four official players implement identically, rather than using newer features with uneven support. ### Does the Lottie contain my artwork? No, and that is deliberate. It carries a placeholder sized to your object; the motion is on the transform, so swapping in real artwork keeps the animation exactly and lets one motion file drive different assets. ## Where to go next - [Figma Motion export to Lottie](https://systergon.com/figma-motion-export-to-lottie) — the complete step-by-step. - [Figma Motion and Lottie](https://systergon.com/figma-motion-lottie) — what Lottie is and why teams standardise on it. - [Figma Motion export Lottie](https://systergon.com/figma-motion-export-lottie) — the developer handoff conversation. - [Figma Motion Lottie export](https://systergon.com/figma-motion-lottie-export) — the panel and the file, field by field. - [Motion Path help centre](https://systergon.com/motion-path/help) — paths, timing, effects and troubleshooting. [Install Motion Path — it’s free →](https://www.figma.com/community/plugin/1654530170219655744) [Browse 300+ animation examples](https://systergon.com/motion-path/examples) ## Related guides - [Figma Motion Export to Lottie](https://systergon.com/figma-motion-export-to-lottie) — Step-by-step instructions for turning a Figma Motion animation into a Lottie JSON file using the Motion Path plugin, including where the export lives, what the file contains and what it cannot carry. - [Figma Motion and Lottie](https://systergon.com/figma-motion-lottie) — An orientation piece on Figma Motion and Lottie: what Lottie is, why product teams standardise on it, what native Figma Motion can and cannot hand over, and how the gap is closed. - [Figma Motion Export Lottie](https://systergon.com/figma-motion-export-lottie) — The developer handoff for a Lottie exported from Figma Motion — what the engineer receives, how each platform player loads it, and the caveats to communicate about looping, artwork and unsupported effects. - [Figma Motion Lottie Export](https://systergon.com/figma-motion-lottie-export) — A reference for the Lottie export panel in Motion Path — the tab layout, the copy and download buttons, the structure of the emitted Lottie 5.9 document, and the notes that list what was left out.