One Drawing, Many Destinations

Excalidraw’s structured scene becomes valuable when it leaves the live canvas. This chapter follows that transition from construction and restoration to JSON, image, SVG, and library outputs. The focus is not a raw schema inventory; it is the lifecycle question of what survives at each boundary, what must be repaired before the scene is trusted, and why a visible export is not the same thing as an editable document. Readers should finish able to choose the right representation for a drawing and to recognize where its images and relationships can still fail.

The previous chapter treated rendering as one projection of the scene. Portability is another. A scene imported from an older file, sent to a host application, converted into a library item, or exported as an image must pass through a boundary that has different consumers and different guarantees.

From construction to a usable scene

A new element begins with defaults and identity rather than with an unstructured command. The constructors assign an ID, geometry, style values, a roughness seed, version information, timestamps, and the fields appropriate to the element type. Text is measured when it is created. Its font, line height, alignment, dimensions, and anchor are calculated together so that the stored record can be rendered consistently instead of relying on one browser’s later guess about the text box.

This construction step is also where the project establishes assumptions that later stages depend on. A linear element needs a point sequence. An arrow needs endpoint fields that can eventually bind to another element. An image needs a file identifier and a status even when the file has not finished loading. A sticky note needs the relationship between its container geometry and its label. The result is not necessarily a finished user action—some tools begin with a zero-sized draft—but it has the shape of a canonical Excalidraw record.

External data enters through a different path. A JSON parser can tell that a value is an array, but it cannot by itself ensure that an arrow has valid points, that an old text record has the fields current layout code expects, or that a container and its label agree about their relationship. Excalidraw’s restoration process supplies defaults, migrates legacy properties, normalizes dimensions and points, repairs bindings, removes unsupported legacy selection data, deduplicates IDs, and repairs container/text relationships after the full collection is available.

Restoration is therefore an algorithm between an external representation and an active scene. It protects the editor from treating every historical or hand-edited field as already valid. It also preserves unknown properties where forward compatibility requires them, rather than assuming that today’s code knows every field a future or neighboring tool may carry. In a drawing format that is intended to travel, this boundary is as important as the serializer: reading a file means translating it into current invariants, not merely copying its JSON objects into memory.

The repair work is relational. An arrow binding cannot be fully checked without looking up its target. A text element’s container may need to add the text back to its bound-element list, or the text may need to detach if the container no longer exists. A frame membership reference may need to be cleared when its frame is absent. A duplicated ID can damage every later lookup, so restoration gives the duplicate a new identity. These cases show why compatibility is not just a version number at the top of a file. It is the preservation of relationships among records.

Some safeguards are deliberately bounded.