What gets lost when converting .riv to .rev (and what does not)
Converting a .riv into a .rev is reconstruction, and it is worth being precise about what "reconstruction" means. The runtime object stream is complete: every object's type and every property's value is in the file. What is missing is a small amount of *editorial* metadata — the fields the editor maintains for human editing, which the runtime never reads and therefore never exported.
Three of those fields cannot be recovered, because no tool can invent information that was never written down.
The three that cannot be recovered
1. Layer lock state
Whether a layer was locked in the editor is a per-layer property the runtime does not need. A converted project comes back with every layer unlocked. If you work on a team and rely on locking to protect finished parts of a rig, re-lock them after opening.
2. State machine node coordinates
The x/y of every state inside the state machine graph is editor layout information. In a converted project the nodes are laid out automatically from the topology of the graph — a readable arrangement, but not the arrangement the original author chose. It costs nothing to drag them into place once.
3. Library relationships
Which library a component was published to, and the version history of that component, live in the editor's collaboration records. A runtime file carries no trace of them. A component is re-classified as a component if it is nested inside another artboard, and as a plain artboard otherwise — a reasonable guess, but a guess.
What is fully recovered
Everything that describes the artwork and the animation comes back as editable objects:
- the layer tree, with parent/child relationships and sibling order
- vector paths and their vertices, plus fills and strokes
- bones and skinning weights
- every animation, its keyed properties, its keyframes and its easing curves
- state machines with their layers, states, transitions and inputs
- embedded fonts and images
- constraints and data bindings
None of it is flattened into a bitmap, and none of it is approximated: the values are the file's own values, re-encoded for the editor.
Warnings are worth reading
A conversion that cannot re-point a reference says so instead of silently dropping it. Warnings come out grouped by category, so you can see at a glance whether a file converted cleanly or whether a specific class of reference was affected.
If the warnings mention unresolved references on a file you care about, cross-check the result in the editor before you depend on it — and prefer the browser converter's preview for exactly this: you can play the original next to the recovered inventory.
Which file format details matter
The reasons behind all of this are encoding details: .riv and .rev use the same property keys but different wire encodings for ids, doubles and ordering, and the editor keeps a set of properties the runtime never had. Inside the Rive file format walks through the object stream and the two encoding lines.
The practical rule
Convert, then open, then look. Treat the result as a first draft of the original project — an editable, complete starting point with three cosmetic gaps — rather than as a pixel-perfect restoration of what the artist had on screen.
Turn a .riv into an editable .rev
The converter runs entirely in your browser — your file is never uploaded. Preview the animation first, then download the editable project.