Data ownership and portability in Trezio

What actually leaves Trezio when you export your library — the real backup format, what is excluded on purpose, and what "yours" means in practice.

2026-07-29

“Your data, your library” is easy to say and hard to make true. The only version that means anything is a concrete one: what file do you actually get if you export today, what's in it, what's deliberately left out, and what happens if you bring it back in. This is that concrete version for Trezio.

The real export formats

Trezio supports three export formats, and they exist for different reasons rather than as one format wearing three hats.

• JSON — a versioned, structured backup of your library: folders, items, charms, and their relationships. This is the format designed for bringing your data back into Trezio.
• HTML — the standard bookmark-file format used by browsers and tools like Raindrop.io, Chrome, and Firefox. This is the format designed for moving links to or from other bookmark managers.
• CSV — a flat, spreadsheet-friendly listing, useful for review or analysis outside any bookmarking tool.

The JSON backup is versioned on purpose. Every export is tagged with a schema version, currently version 3, so that a restore always knows exactly how to interpret the file it’s reading — including a backup taken with an older version of Trezio.

What's actually in a JSON backup

A JSON export contains your folders and their nesting, your saved items (URLs, text notes, voice notes, screenshots) with their titles, descriptions, notes, and charms, and the organizational structure connecting them. In rough shape, one exported item looks like this:

{
  "backupVersion": 3,
  "exportedAt": "2026-03-01T12:00:00.000Z",
  "items": [
    {
      "id": "…",
      "type": "url",
      "title": "…",
      "description": "…",
      "collectionId": "…",
      "charms": ["reading-list"],
      "mediaUrl": "https://…/storage/…"
    }
  ]
}

What is deliberately excluded

Two exclusions are intentional, not oversights.

Vault credentials are never included in an export, in any format. If an item is marked as a stored credential, its encrypted username and password are skipped entirely — an export is not a route around the vault.

The second exclusion is about size and speed, not secrecy: media such as screenshots and voice-note audio is exported as a reference to its storage location, not as embedded bytes inside the backup file. A restore fetches the media back from that reference rather than unpacking it from the file itself. This keeps backups small and fast to generate, but it does mean a backup file alone is not a fully self-contained copy of your media — it depends on the referenced storage still being reachable.

Restoring a backup

Importing a JSON backup re-creates your folders and items from the file. Each item is restored independently: if one item in a large backup fails to restore — a broken media reference, for instance — the rest of the import continues rather than the whole operation stopping. That also means a restore is not strictly all-or-nothing; it is safe to re-run an import after fixing or investigating a partial failure, since restoring the same item twice does not create duplicates for that item.

What this means in practice

In practice: you can always leave with a real, structured copy of your library. You can always bring a link collection in from or out to another bookmarking tool via HTML. What you cannot do is use an export as a backdoor into someone else’s vault, and you should not treat a JSON file, by itself, as a permanent archive of your screenshots and voice notes — for that, keep the media’s storage reachable, or use Google Drive sync alongside your export as a second copy.