TreeNote
Sign inSign up
Guide & Methodology

Why export and portable formats matter

Export is how you find out whether your notes can leave a tool. Learn what a good export contains, what common formats drop, and how to test portability before you depend on it.

4 min read•743 words•Updated for 2026

Export is a property of your work, not the product

Tools change. Companies get acquired, pricing shifts, a product you rely on stops being maintained, or your own needs move. None of that has to be a crisis if the material you built can leave in a form something else can read.

There is a second, quieter benefit: a tool that makes leaving easy has to keep you by being good. That is a healthier relationship than one held together by the cost of getting out.

What a good export actually contains

The text, obviously — including note bodies, not only titles.
The structure. Hierarchy, order and nesting are usually half the meaning; an export that flattens them has kept the words and lost the argument.
The state that carries meaning. Checked checkboxes, dates and tags are content, not decoration.
A format something else opens. A proprietary archive only your current tool can read is a backup, not an exit.
Everything at once. Per-note export is fine for sharing and useless for moving five years of material.

What the common formats keep and drop

Markdown is widely readable and preserves text and basic formatting. It represents hierarchy as indentation or headings, which usually survives, and it has no standard place for dates, references or completion state.

OPML is built for outlines and carries nesting, order, notes and checkbox state well. It has no standard for dates, styling or cross-references, so those are typically lost in transit between tools.

JSON or a tool's own backup format usually keeps everything, because it was designed to. The catch is that only that tool reads it — excellent as a safety net, useless as a bridge.

PDF and HTML preserve appearance and lose editability. They are archival, not portable in the sense that matters here.

Test the export on day one

Export a branch you actually care about — not a three-line demo.
Open the file in a plain text editor and read it. You should be able to recognise your own work.
Import it into a second tool and look for what changed: missing dates, flattened nesting, lost checkboxes, orphaned references.
Write down what did not survive. That list is the real cost of leaving, and it is much easier to accept knowingly than to discover later.

Be realistic about what portability can be

No format carries everything. Features that are specific to a tool — a particular kind of link, a live reference, a view configuration — usually have nowhere to go, and pretending otherwise sets you up for a bad surprise.

The honest goal is not lossless transfer. It is knowing in advance which parts are portable and which are conveniences you would rebuild. A tool that tells you that plainly is doing you a favour.

How this works in TreeNote

TreeNote reads and writes OPML in both directions, carrying text, notes, checkboxes, checked state and hierarchy — and dropping dates, mirrors, colour and collapsed state, which is stated plainly rather than discovered later. A TreeNote JSON backup keeps all of it for moving between your own devices. Because the workspace is local-first, the file is on your device whether or not you ever press export.

Questions

Test the exit before you need it.

Export one real branch today and read what comes out. It takes five minutes and settles the question.

Put these ideas into practice

TreeNote provides a fast, flexible outliner built around these principles. No sign up required to start.