How Well Do Note Apps Import Your Notes? A Fidelity Roundup

How well a note app imports your notes depends almost entirely on structure. Plain paragraphs, headings, bold and italic survive nearly any importer intact. Tables, internal links, embedded images, footnotes, and metadata are where importers silently drop or re-model your data — so score the transfer before you commit to it.

The reason is structural, not a vendor failing. "Because there is no unambiguous spec, implementations have diverged considerably," writes John MacFarlane, author of the CommonMark specification — "users are often surprised to find that a document that renders one way on one system (say, a GitHub wiki) renders differently on another."¹ Markdown is not one format; it is a family of dialects that disagree at the edges. So when an importer converts your notes, it translates between formats that lack feature parity, and translation is lossy exactly where the two formats fail to overlap. Obsidian's own importer states the goal plainly: your notes are "converted to plain text Markdown files."² That conversion is clean for prose and brutal for anything the destination cannot model. This roundup scores five real destinations on where that line falls.

What does import fidelity actually mean?

Import fidelity is how faithfully a destination app reconstructs the structure of the notes you bring it. It is not one number but a spectrum measured per structure type: prose and basic formatting sit at the safe end; tables, internal links, embedded files, footnotes, and metadata sit at the fragile end, where importers quietly drop or transform data.

Most migration guides stop at "click Import." The harder question is what the file looks like on the other side. An app can advertise that it imports "from anywhere" and still flatten a database, guess at a link, or discard a tag tree — because importing is not copying, it is converting.² Fidelity is the gap between the note you handed over and the note you get back. The only way to know the gap is to name the structures you care about and check each one, rather than trust the marketing verb "import."

Why does importing lose data at all?

Importing loses data because "Markdown" is not a single format. HTML, ENEX, and the many Markdown dialects lack feature parity, so any importer is translating between formats that do not fully overlap. Where they do not overlap — a Notion database view, an Evernote tag tree, a wiki link — the importer must guess, flatten, or drop.

Ricardo Mendonça Ferreira, who wrote the open-source evernote2obsidian converter, names the mechanism directly: "HTML (the note format in Evernote) and Markdown (.md, used by Obsidian) lack feature parity, making such conversion potentially lossy."³ Internal links are the sharpest example. Converters "convert Evernote data from .enex files, but those files are missing note link information, so they can only 'guess' how to link to a note."³ The loss is not carelessness. It is what happens when a rich source format is poured into a container that has no slot for part of it. The villain is the parity gap, not any app.

The eight-axis import-fidelity rubric

Score each destination on eight axes, zero to three: nested lists, tables, internal or wiki links, embedded images and attachments, footnotes, YAML frontmatter, code blocks, and a round-trip check. The round-trip is the honest one — import a known note, reopen it in a neutral Markdown reader, and count what changed. The other seven predict; the round-trip measures.

The eight axes, from most to least survivable:

1. Nested lists — usually fine, but deep indentation and mixed ordered/unordered nesting can flatten.
2. Tables — fragile; often re-modeled into a database or degraded on complex cells.
3. Internal / wiki links — the classic casualty; resolved only if source and target import together.
4. Embedded images and attachments — depends on whether the source ships a bundle or bare references.
5. Footnotes — rarely documented, frequently dropped.
6. YAML frontmatter — metadata blocks are ignored by importers built around prose.
7. Code blocks — usually survive as text, but language tags can vanish.
8. Round-trip — the ground truth: what actually came back.

The single fact that predicts most of a destination's score is whether it stores your notes as plain files at all.

flowchart TD
  A[Your notes<br/>+ their structure] --> B{Destination stores<br/>plain Markdown files?}
  B -->|Yes| C[Import is a<br/>file copy]
  C --> D[Nothing to<br/>reconstruct]
  B -->|No| E[App re-models<br/>into blocks/DB]
  E --> F[Loss lands on<br/>tables, links, embeds]
  E --> G[and on footnotes,<br/>metadata]

Figure: where import fidelity is set. If the destination stores plain Markdown files, importing Markdown is a file copy and there is nothing to reconstruct. If the destination re-models notes into blocks or a database, it must transform them on the way in — and transformation is where tables, links, embeds, footnotes, and metadata are lost.

How the apps score: an import-fidelity roundup

On a shared rubric, no destination is uniformly best. Obsidian is near-lossless from a dedicated source like Apple Notes but lossier from block-and-database apps; Notion re-models everything into pages and properties; Joplin's ENEX path is explicitly lossless for basic formatting; Bear accepts many formats but documents little about what degrades. Read the table by structure, not by winner.

Two patterns fall out of the table. First, a destination that stores plain Markdown files has almost nothing to reconstruct — importing Markdown is a file copy. Second, an app that re-models notes into blocks or a database, like Notion, pays a transformation cost on every rich structure, and that cost is documented in its own help pages.⁶

Where importers silently fail

Five structures break most often, and vendors document it in their own words. Notion warns that "complex tables, special callouts, and advanced formatting may degrade."⁶ Obsidian notes that Evernote "export does not keep the tag hierarchy"⁵ and that only "the primary view for each database is imported."⁴ These are not accidents; they are the parity gap, named.

Work through them in the order they cost you:

• Tables collapse or convert. A Notion CSV import turns a grid into a database — "Rows import as pages"⁶ — while Joplin instead converts tables to Markdown tables.⁷ Same word, "import," two very different results.
• Internal links break unless everything moves together. Evernote's .enex files are "missing note link information," so a converter can only "guess."³
• Embedded images may arrive broken. Notion states images "may not render correctly and may need cleanup after import."⁶
• Metadata is quietly re-modeled. Evernote notebooks become Notion pages and notes become database items;⁶ Evernote's tag hierarchy is dropped on the way into Obsidian.⁵
• Footnotes and frontmatter are the least-documented axes of all — which is why you cannot trust a help page to tell you, and have to test.

If your import lands messy, cleaning it back into plain Markdown is its own discipline, covered in cleaning up a vendor export into plain Markdown.

When import is near-lossless

Import can be near-lossless when a dedicated importer meets a rich source format. Obsidian's Apple Notes importer "supports virtually all Apple Notes content types," including "tables, images, drawings, scans, PDFs."⁹ Joplin calls its ENEX import "a lossless conversion" for basic formatting and even converts tables to Markdown tables.⁷ The parity gap narrows when both sides speak the same rich format.

The lesson is not "importers are bad." It is that fidelity is a property of the specific importer plus the specific format pair — not a universal law. A purpose-built converter can recover metadata a generic importer drops. Obsidian's official Evernote import leans on Yarle, written by Akos Balasko, which was designed to put "title, creation time, update time, tags, and latlong … into md as metadata."¹⁰ Two apps importing the same file can land far apart, because one was engineered to preserve exactly the structure the other ignores. When a vendor publishes precisely what degrades, as Notion and Joplin both do,⁶⁷ treat that honesty as a feature, not a warning to flee.

The shared round-trip test note

The only honest fidelity test is a round-trip. Below is a shared Markdown note that packs every fragile structure into one file: nested lists, a table, a wiki link, an embed, a footnote, frontmatter, and a code block. Copy it, import it into any app, reopen it, and count what survived. The gaps are your migration to-do list.

---
title: Import Fidelity Test Note
tags: [migration, test, portability]
created: 2026-07-23
---

# Import fidelity test note

A plain paragraph with **bold**, *italic*, and `inline code`. This line
is the control: it should survive every importer unchanged.

## Nested lists

- Top level
  - Second level
    - Third level
      1. Ordered inside unordered
      2. Second ordered item

## A table

| Structure   | Survives? | Notes                     |
|-------------|-----------|---------------------------|
| Paragraphs  | Usually   | The easy case             |
| Tables      | Sometimes | Watch alignment + nesting |
| Footnotes   | Rarely    | The first thing to break  |

## An internal link and an embed

A wiki-style internal link: [[Another Note]].
A standard Markdown link: [see the table](#a-table).
An embedded image: ![A diagram](./assets/diagram.png)

## A footnote

Here is a claim that needs a source.[^src]

## A code block

```python
def survives(structure: str) -> bool:
    return structure == "plain prose"
```

[^src]: The footnote body. If this line vanishes on import, footnotes are lost.

Score each structure zero to three: 3 = identical, 2 = present with minor drift, 1 = present but broken, 0 = gone. Run the same file through every app on your shortlist and the scores are directly comparable — which is the whole point of a shared corpus. A round-trip check like this is old, diffuse quality-assurance practice, not any one person's invention; build your own corpus and keep it in version control so you can re-run it whenever an importer updates.

Who should score their import — and who can skip it

Run the test if you keep tables, wiki links, embedded files, footnotes, or per-note metadata — the structures that break. You can skip it if your notes are mostly prose, headings, and basic formatting, which survive nearly any importer. And check the direction that matters: leaving an app and arriving in one are different failure sets.

An app can export clean Markdown yet import tables badly, or the reverse — so the inbound question here is only half of migration. The outbound half, how much survives when you leave an app, is scored in the companion export-fidelity roundup. Be honest about the trade, too: a plain-file destination has nothing to reconstruct precisely because it does not offer blocks, databases, or proprietary embeds in the first place. If those features are why you love your current app, a "lossless" import may simply mean the rich parts had nowhere to land. The durable question underneath all of this is whether your notes will still open when the app is gone — the subject of note apps that outlive the company.

Frequently asked questions

These are the questions migrators actually ask before they commit, answered from each app's own import documentation and a round-trip check. Verify the specifics on the day you migrate: vendor importers are undated, rolling documents, and their behavior changes without a changelog or a warning to the people relying on it.

Does Obsidian import keep my links and tables? Partly. Obsidian's importer converts notes to "plain text Markdown files,"² and reconciles Notion internal links when pages are imported together. But "only the primary view for each database is imported,"⁴ so database tables collapse, and Evernote links are "guessed" because ENEX files are "missing note link information."³ Expect prose to survive and structured data to need repair.

Will I lose formatting importing Evernote into Notion? Some. Notion states that when importing Evernote, images "may not render correctly and may need cleanup after import,"⁶ and that "complex tables, special callouts, and advanced formatting may degrade."⁶ Your notebooks are also re-modeled: "Evernote notebooks import as pages, and notes import as database items."⁶ Plan for manual cleanup on anything beyond basic text.

Does importing Markdown into Notion keep the structure? Not entirely. Notion warns that "anchor links and nonstandard Markdown extensions may not import cleanly."⁶ A CSV table does not stay a table either: "Rows import as pages"⁶ and columns become properties, turning a simple grid into a database. Standard prose imports fine; anything using extended or linked syntax needs checking afterward.

Does Joplin import ENEX without losing data? Mostly, for basic notes. Joplin can import "notes, tags, resources (attached files) and note metadata (such as author, geo-location, etc.) via ENEX files,"⁷ and calls basic-formatting conversion "lossless."⁷ But not everything survives: Evernote image-recognition data "is not preserved when the note are imported into Joplin."⁷ Rich formatting and OCR layers are the exceptions.

How do I import notes into Bear? Bear accepts a broad set of files: plain text, Markdown, Rich Text Format, Text Bundle and Text Pack, Evernote's ENEX export, Bear's own note format, and HTML.⁸ That wide intake makes Bear a convenient destination, but its documentation lists the formats it accepts rather than what degrades on import — so run the round-trip test to see per-structure loss.

Does a note app import keep footnotes, frontmatter, and code blocks? It varies, and these are the least-documented axes. Footnotes and YAML frontmatter are the first casualties, because most importers were built around prose and attachments, not reference syntax or metadata blocks. Code blocks usually survive as text but can lose language tags. None of this is stated on vendor pages — which is exactly why the round-trip test exists.

Is a Markdown-to-Markdown import always lossless? No. Even Markdown-to-Markdown can drift, because Markdown dialects "have diverged considerably,"¹ as CommonMark's author puts it. A plain-file destination that simply stores your Markdown copies the bytes with nothing to reconstruct, which is the safe case. But if either side uses extended syntax the other does not recognize, the parity gap reappears even between two Markdown apps.

Migration is not a button; it is a translation, and every translation drops what the two formats do not share. The safest transfer is the one with the least to translate — but that safety is only real for the structures you actually keep. Score the transfer, save the note that proves what broke, and carry the file forward rather than your faith in the importer.

Notes written as plain, open Markdown on your own device have nothing to reconstruct on the way in — the quiet case that mnmnote.com is built around.