Overview: What “Readable” Means for an Agent
Most motion-format comparisons ask which one looks better or animates faster. This one asks a narrower, more mechanical question: which format can an AI agent read?
That question needs a definition before it needs a winner. In this post’s analysis, an agent “reads” a motion format when it can do three things without a human in the loop: parse the file into structured data, validate that data against a known structure, and diff two versions to describe what changed. Rendering is a separate capability — a format can render beautifully and still be opaque to a parser. The three-part definition (parse, validate, diff) is the yardstick used throughout this comparison, and it is the author’s framing rather than a claim taken from either vendor’s documentation.
Against that yardstick, the two formats diverge sharply:
An AI agent can read, validate, and diff Lottie animations today because their logic lives in schema-validated JSON, while Rive’s logic lives in a state-machine and view-model graph that agents must approach through editor and runtime APIs rather than a published schema — making Lottie the more agent-legible format, and Rive the more agent-controllable one at runtime.
The rest of this post unpacks that sentence dimension by dimension, scores both formats across five criteria, and ends with a job-based verdict rather than a single winner.
Lottie: Logic as Legible JSON
Lottie’s position is unusually clean for an agent. The official documentation states that “Lottie is a vector animation format, using JSON to represent its data,” and that the top-level JSON object is the Animation (Lottie Docs Introduction). There is no binary container to reverse-engineer and no editor session required to inspect the contents: the animation is the file, and the file is text.
Two details strengthen the case. First, the format is registered with the internet media type video/lottie+json and the .lot file extension (Lottie Docs Introduction), which means the payload is identifiable as JSON at the transport level rather than as an opaque blob. Second, a machine-readable JSON Schema is published alongside the human-facing guide — a full schema, draft 2020-12, with $id lottie.schema.json, explicitly intended “for tools that parse or generate Lottie” (Lottie Schema).
That schema is not decorative. It defines assets, values and bezier shapes, and it enumerates required keys — for example, a bezier requires i, v, and o (Lottie Schema). For an agent, that is the difference between “this file is probably fine” and “this file conforms to a published contract, and here is the exact key that violates it.” Validation stops being a heuristic and becomes a lookup.
The guide’s own scope is narrow: it describes the format for humans and does not cover how to animate or export from an editor (Lottie Docs Introduction). That suits an agent-facing reference, which needs the artifact, not the authoring workflow.
Rive: Logic as a Graph, Not a File
Rive’s documentation describes a genuinely richer behavioral model, but it describes it as editor concepts rather than as a file specification.
State Machines are composed of a Graph, States (timeline animations), Transitions and Layers, and “every artboard has at least one State Machine by default” (Rive State Machine Docs). That default is significant: behavior is not an add-on bolted onto an animation; it is the baseline condition of every artboard. The same page frames state machines as a collaboration surface between designers and developers, noting that using them requires thinking like a developer, “in a straightforward, visual way” (Rive State Machine Docs).
Data Binding adds a second logical layer. View Models define the data structure, View Model Instances store values, and Bindings connect that data to scene properties — position, color, health, and the swapping of images, artboards or components (Rive Data Binding Docs). Data can be updated from the Editor, from runtime code, from state machines, or from scripting, and scene changes write back to the data (Rive Data Binding Docs).
For an agent, the shape of this matters more than the feature list. The logic is real, explicit, and documented — but an agent reaches it through the editor or through runtime APIs. The documentation reviewed publishes no Rive file schema; the concepts are documented as editor and runtime constructs rather than as a machine-readable specification (Rive State Machine Docs). Whether a Rive file could be parsed and validated the way a Lottie file can is not verified here, and this post does not speculate about it.
Dimension Scores
The table below scores both formats from 1 to 5 across five criteria. Every factual cell cites a source or is marked not verified. Scores are editorial judgments on the parse-validate-diff definition from the overview, not measures of product quality.
| Criterion | Lottie | Rive |
|---|---|---|
| Published schema | 5 — A full JSON Schema (draft 2020-12, $id lottie.schema.json) is published for tools that parse or generate Lottie, defining assets, values and bezier shapes and required keys (Lottie Schema); the format is registered as video/lottie+json with the .lot extension (Lottie Docs Introduction). |
1 — No published Rive file schema appears in the documentation reviewed; logic is documented through editor concepts such as State Machines and View Models rather than a machine-readable spec (Rive State Machine Docs). Rive file internals: not verified. |
| Logic readability (for a parser) | 5 — “Lottie is a vector animation format, using JSON to represent its data,” and the top-level JSON object is the Animation (Lottie Docs Introduction). | 2 — Logic is explicit and documented (Graph, States, Transitions, Layers; View Models, View Model Instances, Bindings) but lives in a graph an agent reads via editor or runtime APIs, not a parseable file (Rive State Machine Docs; Rive Data Binding Docs). |
| Runtime coupling | 3 — The portable baseline is “Level 0: Regular Lotties”; interactivity beyond playback requires expressions, a JS wrapper and the lottie-web player, and is officially described as “less portable” (Lottie Advanced Interactions). | 4 — Interactivity is native to the state machine; data can be updated from runtime code, state machines or scripting, and scene changes write back to data (Rive Data Binding Docs). |
| Portability of interactive logic | 2 — The same source describes expression and JS-wrapper techniques as “less portable,” sorts them into levels 0–9, and expects knowledge of JavaScript and the DOM (Lottie Advanced Interactions). | 3 — Bindings let you rename or reorganise scene elements without rewriting runtime code (Rive Data Binding Docs); cross-runtime portability beyond this is not verified. |
| Diffability | 4 — JSON text plus a published schema means structural diffs are computable; this is the post’s analysis inferred from Lottie Schema, not a source claim. The dotLottie packaging layer bundles multiple animations, states and icons with shared assets (dotLottie), a vendor page. | Not scored — no verified file-format specification was fetched, so diffability of Rive files is not verified. |
Read the table as two different strengths rather than one winner. Lottie leads on schema, logic readability and diffability, because its logic is exposed as text with a published contract. Rive leads on the two runtime-facing rows, where behavior is native rather than reconstructed through a scripting layer.
Where Each Format’s Interactivity Lives
This is the dimension where the two formats stop being comparable and start being different tools.
On the Lottie side, interactivity beyond simple playback is built with expressions, a JS wrapper and the lottie-web player. The official page is candid about the trade-off: it calls these techniques “less portable,” sorts them into levels 0 through 9, and expects the reader to have knowledge of JavaScript and the DOM (Lottie Advanced Interactions). The portable baseline is explicitly “Level 0: Regular Lotties” — meaning that as soon as an animation needs to respond to input, it leaves the schema-validated, portable core and enters a JavaScript-dependent tier (Lottie Advanced Interactions).
The packaging layer softens this somewhat. According to the dotLottie vendor page, a .lottie file bundles multiple animations, states and icons with shared assets, and — as a vendor claim — “State machines handle click, hover, and completion events without custom code” (dotLottie). That claim is worth flagging precisely because it is a vendor claim on a product page, not a schema-level guarantee. The same page also makes a Deflate-compression size claim, which is likewise a vendor claim with no figures attached (dotLottie).
On the Rive side, interactivity is not a layer added on top of the animation — it is the state machine itself. States are timeline animations, Transitions move between them, and Layers organise the graph (Rive State Machine Docs). Data Binding then connects runtime values to scene properties, and the write-back behavior means the scene and the data stay in sync in both directions (Rive Data Binding Docs).
The net effect: Lottie trades runtime-native behavior for file-level legibility, while Rive trades file-level legibility for runtime-native behavior. Neither trade is a defect. They simply point at different agent jobs.
Verdict: Which Format for Which Job
Lottie wins when the agent’s job is reading, validating, and diffing. Schema-validated JSON is the strongest possible position for the question “what can an agent perceive?” An agent can parse the file, validate it against the published schema, and diff two versions as text. No editor session, no runtime, no API handshake is required to answer “what changed between these two animations?” That is a complete, self-contained loop.
Rive wins when the agent’s job is driving a live scene. Data Binding — View Models, View Model Instances, and Bindings to position, color, health, and image, artboard or component swapping — plus write-back from scene to data makes Rive the richer control surface (Rive Data Binding Docs). An agent operating a running scene can update data from runtime code or scripting and see the scene respond, and it can rename or reorganise scene elements without rewriting runtime code (Rive Data Binding Docs). What it cannot do, on the documentation reviewed, is read a published file schema to get there.
The honest middle: dotLottie adds state-machine-style behavior to the Lottie side, but that capability arrives as a vendor claim on a product page rather than as a schema guarantee (dotLottie). Treat it as a promising direction, not a settled equivalence.
Honest Limits: What This Comparison Doesn’t Cover
This review is based on official documentation only; no hands-on testing was performed.
Several load-bearing questions remain open, and they are listed here as gaps rather than filled with estimates:
- No measured file-size comparison was fetched. No byte counts, compression percentages, or “smaller than” figures appear in this post. The dotLottie Deflate claim is a vendor claim with no numbers attached (dotLottie).
- No render-performance comparison was fetched. This post makes no performance statements about either format.
- No verified Rive file-format specification was fetched. Nothing in this post describes how a Rive file is encoded.
- The Rive runtime documentation was not available when this was researched, so no runtime-level behavior is described beyond the editor and data-binding pages.
- No hands-on testing was performed — no format was run, rendered, parsed, or benchmarked by the author.
FAQ
Can an AI agent parse a Lottie file without special tooling?
Yes, in principle. Lottie uses JSON to represent its data, and the top-level JSON object is the Animation (Lottie Docs Introduction). A published JSON Schema (draft 2020-12, $id lottie.schema.json) exists for tools that parse or generate Lottie (Lottie Schema).
Can an AI agent parse a Rive file the same way? That is not verified here. Rive’s logic is documented through editor concepts — State Machines with a Graph, States, Transitions and Layers, and Data Binding with View Models, Instances and Bindings — reached through editor or runtime APIs (Rive State Machine Docs; Rive Data Binding Docs).
Does Lottie support interactivity, or only playback? It supports interactivity beyond playback through expressions, a JS wrapper and the lottie-web player, but the documentation calls those techniques “less portable” and expects JavaScript and DOM knowledge, with “Level 0: Regular Lotties” as the portable baseline (Lottie Advanced Interactions).
The Bottom Line
If the question is “which motion format can an AI agent read?”, the answer is Lottie — because reading means parsing, validating against a published schema, and diffing as text, and Lottie is the format whose logic lives in schema-validated JSON (Lottie Docs Introduction; Lottie Schema).
If the question is “which motion format can an AI agent control at runtime?”, the answer leans Rive — because Data Binding exposes a documented control surface for position, color, health and asset swapping, with data updatable from runtime code, state machines or scripting (Rive Data Binding Docs).
The mistake would be treating this as a horse race. Lottie is the more agent-legible format; Rive is the more agent-controllable one. Pick by pipeline shape, and state the gaps — file size, render performance, and Rive file internals — as gaps until someone fetches the evidence.