--- title: Persistence created_at: 12/29/2025 updated_at: 12/29/2025 keywords: - persistence - save - load - snapshot - indexeddb - localstorage - migrations - storage status: published date: 12/29/2025 readability: 9 voice: 9 completeness: 8 accuracy: 10 notes: '' --- In tldraw, persistence means storing the editor's state to a database and restoring it later. The SDK provides several approaches: automatic local persistence with a single prop, manual snapshots for custom storage backends, and a migration system for handling schema changes. ## The persistenceKey prop The simplest way to persist an editor is with the `persistenceKey` prop: ```tsx import { Tldraw } from 'tldraw' import 'tldraw/tldraw.css' export default function App() { return (
) } ``` With this prop, the editor saves to IndexedDB whenever it changes and loads from IndexedDB on mount. It also stores assets alongside the document and keeps tabs with the same key in sync. Under the hood this is the internal `useLocalStore` hook. Each persistence key represents a separate document: ```tsx ``` Two editors with the same key share the same document and stay in sync. Each editor still maintains its own session state (camera position, selection, current page), saved per tab under the `sessionId` prop, which defaults to a unique id for the tab. ## Snapshots For custom storage backends, use snapshots to save and load editor state. A snapshot is a JSON-serializable object containing the full document. ### Getting a snapshot Call [getSnapshot](?) with the editor's store (or [Editor#getSnapshot](?)) to get the current state: ```ts import { getSnapshot } from 'tldraw' const { document, session } = getSnapshot(editor.store) ``` The snapshot has two parts: | Part | Contents | When to share | | ---------- | ----------------------------------------- | ----------------------------- | | `document` | Shapes, pages, bindings, assets | Save to server in multiplayer | | `session` | Camera, current page, selection, UI state | Keep per-user locally | For single-user apps, save both together: ```ts localStorage.setItem('my-drawing', JSON.stringify({ document, session })) ``` For multiplayer, save them separately: ```ts await saveToServer(documentId, document) localStorage.setItem(`session-${documentId}`, JSON.stringify(session)) ``` ### Loading a snapshot Call [loadSnapshot](?) (or [Editor#loadSnapshot](?)) to restore state into an existing editor: ```ts import { loadSnapshot } from 'tldraw' const saved = JSON.parse(localStorage.getItem('my-drawing')) loadSnapshot(editor.store, saved) ``` You can load document and session separately: ```ts // Load document from server const document = await fetchFromServer(documentId) loadSnapshot(editor.store, { document }) // Optionally load session from local storage const session = JSON.parse(localStorage.getItem(`session-${documentId}`)) if (session) { loadSnapshot(editor.store, { session }) } ``` Loading a `document` on its own preserves the editor's current session state. Pass `{ forceOverwriteSessionState: true }` as a third argument to replace it with the snapshot's session instead. ### Initial state Pass a snapshot to the `Tldraw` component to initialize with saved data: ```tsx import { useState, useEffect } from 'react' import { Tldraw, TLEditorSnapshot } from 'tldraw' import 'tldraw/tldraw.css' export default function App() { const [snapshot, setSnapshot] = useState(null) useEffect(() => { async function load() { const document = await fetchDocument(documentId) const session = getLocalSession(documentId) setSnapshot({ document, session }) } load() }, []) if (!snapshot) return
Loading...
return (
) } ``` ## Custom persistence with store For more control, create your own store and pass it to the editor. This lets you load data before mounting and implement custom sync logic. ### Creating a store Use [createTLStore](?) to create a standalone store: ```tsx import { useState } from 'react' import { createTLStore, loadSnapshot, Tldraw } from 'tldraw' import 'tldraw/tldraw.css' export default function App() { const [store] = useState(() => { const store = createTLStore() const saved = localStorage.getItem('my-drawing') if (saved) { loadSnapshot(store, JSON.parse(saved)) } return store }) return (
) } ``` ### Async loading with TLStoreWithStatus When loading data asynchronously, use [TLStoreWithStatus](?) to handle loading and error states: ```tsx import { useState, useEffect } from 'react' import { createTLStore, loadSnapshot, Tldraw, TLStoreWithStatus } from 'tldraw' import 'tldraw/tldraw.css' export default function App() { const [storeWithStatus, setStoreWithStatus] = useState({ status: 'loading', }) useEffect(() => { let cancelled = false async function load() { try { const snapshot = await fetchSnapshot() if (cancelled) return const store = createTLStore() loadSnapshot(store, snapshot) setStoreWithStatus({ status: 'synced-local', store }) } catch (error) { if (cancelled) return setStoreWithStatus({ status: 'error', error: error as Error }) } } load() return () => { cancelled = true } }, []) return (
) } ``` The editor shows the `LoadingScreen` component while the status is `loading`, throws the `error` to the nearest error boundary, and renders normally for the other statuses. The possible values are: | Status | Meaning | | --------------- | ------------------------------------------------------------------- | | `loading` | The store is loading | | `error` | Loading failed | | `not-synced` | Store created without persistence | | `synced-local` | Store loaded from local storage | | `synced-remote` | Store synced with remote server (includes `connectionStatus` field) | ## Listening for changes Subscribe to store changes with [Store#listen](?) to implement auto-save or sync: ```ts const cleanup = editor.store.listen((entry) => { for (const record of Object.values(entry.changes.added)) { console.log('Added:', record.typeName, record.id) } for (const [prev, next] of Object.values(entry.changes.updated)) { console.log('Updated:', next.id) } for (const record of Object.values(entry.changes.removed)) { console.log('Removed:', record.id) } }) ``` The `listen` method returns a cleanup function you should call when unmounting. ### Filtering changes Filter by source and scope to listen for specific changes: ```ts // Only user changes (not remote sync) editor.store.listen(handleChanges, { source: 'user', scope: 'all' }) // Only document records (not session state) editor.store.listen(handleChanges, { source: 'all', scope: 'document' }) ``` | Filter | Values | Purpose | | -------- | ------------------------------------------------ | ----------------------- | | `source` | `'user'`, `'remote'`, `'all'` | Where changes came from | | `scope` | `'document'`, `'session'`, `'presence'`, `'all'` | Type of records | ### Throttled auto-save Here's a pattern for auto-saving with throttling (`lodash` isn't a tldraw dependency, so bring your own throttle): ```ts import { throttle } from 'lodash' import { getSnapshot } from 'tldraw' const saveToStorage = throttle(() => { const snapshot = getSnapshot(editor.store) localStorage.setItem('my-drawing', JSON.stringify(snapshot)) }, 500) const cleanup = editor.store.listen(saveToStorage) ``` ## Remote changes When synchronizing with a multiplayer backend, use [Store#mergeRemoteChanges](?) with [Store#put](?) and [Store#remove](?) to apply updates from other users: ```ts myRemoteSource.on('change', (changes) => { editor.store.mergeRemoteChanges(() => { for (const change of changes) { if (change.type === 'add' || change.type === 'update') { editor.store.put([change.record]) } else if (change.type === 'remove') { editor.store.remove([change.id]) } } }) }) ``` Changes inside `mergeRemoteChanges` are tagged with `source: 'remote'`. This lets you filter them out when listening, so you don't create an infinite sync loop: ```ts // Only save user changes, not remote changes editor.store.listen(saveToServer, { source: 'user', scope: 'document' }) ``` For production multiplayer apps, use the [@tldraw/sync](/docs/sync) package instead of building your own sync layer. ## Migrations Snapshots include schema version information. When you load a snapshot from an older version, the store migrates it automatically. You don't need to do anything for tldraw's built-in types. ### Shape props migrations If you have custom shapes, define migrations to handle changes to their props over time: ```ts import { createShapePropsMigrationIds, createShapePropsMigrationSequence, ShapeUtil } from 'tldraw' // Version IDs must start at 1 and increment const versions = createShapePropsMigrationIds('my-shape', { AddColor: 1, RenameSize: 2, }) const migrations = createShapePropsMigrationSequence({ sequence: [ { id: versions.AddColor, up(props) { props.color = 'black' }, down(props) { delete props.color }, }, { id: versions.RenameSize, up(props) { props.dimensions = props.size delete props.size }, down(props) { props.size = props.dimensions delete props.dimensions }, }, ], }) // Attach migrations to your shape util class MyShapeUtil extends ShapeUtil { static override type = 'my-shape' as const static override migrations = migrations // ... } ``` Multiplayer sync uses the `down` migrations when a peer is running an older schema version. ### General migrations For migrating other data like `meta` properties, use the general migration API: ```ts import { createMigrationIds, createMigrationSequence } from 'tldraw' const sequenceId = 'com.example.my-app' const versions = createMigrationIds(sequenceId, { RemoveLegacyField: 1, }) const migrations = createMigrationSequence({ sequenceId, sequence: [ { id: versions.RemoveLegacyField, scope: 'record', filter: (record) => record.typeName === 'page', up(page: any) { delete page.meta.legacyField }, }, ], }) ``` Pass migrations to the `Tldraw` component or when creating a store: ```tsx ``` ```ts const store = createTLStore({ migrations: [migrations] }) ``` ### Migration scopes Migrations support different scopes depending on what you need to change: | Scope | Use case | | --------- | ----------------------------------------------------------------------------------------------------------------- | | `record` | Runs on individual records matching an optional filter | | `store` | Receives the entire serialized store for cross-record changes | | `storage` | Receives a `SynchronousRecordStorage` with `get`, `set`, `delete`, `keys`, `values`, and `entries`. Has no `down` | Most migrations use `record` scope. Use `store` or `storage` when you need to read or modify multiple records together. ## Examples - [Persistence key](/examples/configuration/persistence-key) - Automatic local persistence with a single prop - [Snapshots](/examples/editor-api/snapshots) - Saving and loading editor state - [Local storage](/examples/data/assets/local-storage) - Custom persistence with throttled auto-save - [Store events](/examples/events/store-events) - Listening to store changes - [Shape with migrations](/examples/shapes/tools/shape-with-migrations) - Migrations for custom shape props - [Meta migrations](/examples/data/assets/meta-migrations) - General migrations for meta properties