Where Do Your Images and Attachments Actually Live? A Note-App Media Audit

Your notes are portable until the first image. After that, portability depends entirely on where the app put the picture: inline inside the note file, in a sidecar file beside it, inside an app database, or in a cloud blob behind an expiring link. Four models, four very different answers to "will my images come with me?"

The text is the easy half. Words live inside the .md file, so they travel anywhere a plain editor reaches. A picture is a separate object the text merely names, and each app decides on your behalf where that object lands. This audit reads eight tools' own documentation and sorts them into the four storage models, so you can tell which decision your app made before an export forces you to find out.

Our companion essay makes the conceptual case that Markdown is portable until you add an image. This piece does the app-by-app scoring that essay concedes: not why the seam exists, but where, in each of eight named tools, the bytes actually sit.

What are the four ways a note app can store an image?

There are four. Inline base64 encodes the image bytes as text inside the note file itself. A sidecar file keeps the picture as a real file beside the note, referenced by a relative path. An app-database bundle stores it inside a database. A cloud blob keeps it on a server, reached by a link.

The baseline that these four diverge from is Markdown's own image syntax, which stores a reference, not the bytes. The CommonMark specification defines a link destination as "a nonempty sequence of characters that does not start with <, does not include ASCII control characters or space character."¹ That is a text string pointing elsewhere — a direction, not a possession. Everything below is a decision about what sits at the other end of that string.

The point of sorting apps this way is that the model, not the brand, predicts the behavior. Two apps in different buckets can look identical while you use them and behave completely differently the day you move a note.

The portable baseline: sidecar files with relative paths

The sidecar model is the portable baseline, and four tools use it: Obsidian, Logseq, Joplin, and Typora. In each, the image is a real file on your disk, and the note holds a relative path to it. Move the folder and the picture moves with it — the link keeps resolving because it points nowhere but next door.

Obsidian is the plainest example. Its help documentation states, "Attachments are regular files that you can access using your file system."² A regular file is a thing you can see, copy, and back up yourself — the storage model that gives you the most control, because nothing sits between you and the bytes.

Joplin reaches the same place by a slightly different route. Its documentation says, "Any kind of file can be attached to a note. In Markdown, links to these files are represented as a simple ID to the attachment."³ Internally that ID points at a file in Joplin's resources/ directory; a Markdown export rewrites it into a relative path so the picture travels with the note.

Typora makes the choice explicit and configurable. Its default, per Typora's support docs, is to "Copy image files to target folder when inserting local image."⁴ The image is copied to a folder beside the document and linked by a relative path. Logseq follows the same shape, keeping attachments in an assets/ folder in the graph and linking them with a relative ../assets/ path.⁵ In all four, ownership is literal — the files are yours, on your disk, right now.

The database bundle: Bear and Apple Notes

Bear and Apple Notes store your images differently: not as loose files but inside a database. In Bear, the picture lives in a SQLite file the app manages; in Apple Notes, it sits in a media folder keyed to a database record. You cannot copy the image out by hand — it only leaves through an export.

Bear is refreshingly direct about it. Its FAQ states, "Bear's notes are stored in an SQLite database," located at ~/Library/Group Containers/9K33E3U3T4.net.shinyfrog.bear/Application Data/database.sqlite.⁶ Your attachments are rows and blobs inside that single file, not pictures in a folder. That buys fast search and tidy sync, at the cost of hand-portability.

Apple Notes works the same way, though Apple publishes no official storage documentation — so this cell is reverse-engineered, not vendor-stated. Forensic analysis by Yogesh Khatri found notes in a NoteStore.sqlite database with attachments in a Media/<UUID>/ directory.⁷ The design is a legitimate trade for reliability and iCloud sync; it simply means "where is my image" has no answer you can point a file manager at.

The cloud blob: an image behind an expiring link

In Notion and Standard Notes, the image is not on your device at all — it is an object on a server, reached through an API. Notion's own reference says each file URL is "valid for 1 hour"; Standard Notes keeps the blob end-to-end encrypted so its own servers cannot read it. The bytes live off your machine.

Notion is unusually candid in its developer docs. The File object reference explains that a Notion-hosted file "includes a temporary public url valid for 1 hour," carries an expiry_time field, and warns: "Don't cache or statically reference these URLs."⁸ That is the whole portability story in one line. The link in your note is not a durable address; it is a lease that lapses, and once the note leaves Notion the reference is dead.

Standard Notes keeps its blobs on a server too, but encrypts them first. Its help center says attached "Files are end-to-end encrypted using the same technology powering the encryption of your notes,"⁹ and its encryption whitepaper describes treating the server "as a dumb data-store that simply saves and returns values on demand."¹⁰ "End-to-end encrypted" is Standard Notes' documented claim, not a verdict this audit endorses — but the storage model is clear: the image is a server object you retrieve, not a file on your disk.

The inline case: base64 inside the file

The fourth model is the rarest: encode the image as base64 text and paste it directly into the note. A Jupyter notebook does this — the picture becomes a long string of characters living inside the .ipynb file. It is self-contained and travels with the text, at the cost of a file a third larger and unreadable in a plain editor.

The Jupyter notebook format spells out the structure. An attachment is stored as "attachments": {"test.png": {"image/png": "base64-encoded-png-data"}} — the image bytes encoded straight into the notebook's JSON.¹¹ Nothing to lose, because nothing is external.

The trade is real, and it is why almost no note app defaults to this. Base64 encoding uses four characters for every three bytes, which inflates the file by roughly a third (RFC 4648).¹² Worse, it destroys the diff: a one-line ![](path) becomes a paragraph of gibberish, so version history and plain-text search stop working on that note. Inline storage wins on portability and loses on everything else.

The audit, side by side

Here is the same evidence in one table. Every cell is the vendor's own current documentation, read on 2026-07-27, sorted into the four storage models. The column that decides portability is the last one: whether the image survives when you copy the note's folder somewhere else and open it in a different app.

Evernote, Google Keep, and Roam Research belong in the cloud-blob row too, on the same principle — the image is a server object, not a local file — though the specific mechanics vary per vendor.

Will your images survive an export?

This answer follows from the storage model. It is reasoned from each vendor's documented design, not measured in a filesystem test. Sidecar tools survive a folder copy. Database and cloud apps do not — their images are not files you can move, so a naive "copy the notes" leaves every picture behind unless you run the app's own export.

Trace each model to its conclusion. A sidecar file with a relative path travels in the folder, so the link still resolves after a copy — this is why the Markdown baseline, Obsidian, Logseq, Joplin, and Typora survive. A cloud blob like Notion's is a one-hour signed URL the docs tell you not to cache;⁸ the moment the note leaves the app, the reference expires — proven by Notion's own words, not by any test we ran. A database bundle stores the picture as a row, not a file, so a hand copy of your notes folder misses every attachment. And inline base64 always survives, because the picture is the file — at the byte-bloat cost above.

The honest caveat: an app's export usually does the right thing where a hand copy does not. Joplin's Markdown export rewrites resource IDs into relative paths; Notion's and Bear's exporters pull the blobs back out. The failure mode is assuming "my notes are just files" and copying the folder — which is exactly where database and cloud models bite.

Who should care where their images live — and who shouldn't

Not everyone needs sidecar files. If you plan to keep switching apps, archive for the long term, or run your own scripts over your notes, the storage model matters — real files beside the note are the safe bet. If you value cross-device sync, search across a workspace, or team collaboration, a cloud or database model buys you those things honestly.

The database and cloud designs are not mistakes. Server-side blobs are what let Notion search a whole workspace and collaborate in real time; a SQLite bundle is what lets Bear sync and dedupe cleanly. Standard Notes' encrypted blob is a deliberate privacy design, not a portability oversight. Each buys something real in exchange for the loose file you can grab by hand.

The mistake is not choosing a cloud or database app. It is believing your pictures are portable files when the vendor's own docs say they are server objects or database rows. Pick the trade-off on purpose; the durability of the tool itself is a separate question worth asking in the same breath.

How to find out where your own app puts images

You do not have to take any vendor's word for it. Add an image to a test note, then check two things: the raw Markdown source and your file system. A relative path plus a matching file on disk means sidecar storage. A long base64 string in the source means inline. Neither means a database or a cloud blob.

Three quick tells settle almost every case. First, open the note's raw source — if you see ![](something/x.png), follow that path and confirm a real file sits there. Second, search your disk for the image by name; sidecar apps let you find it, database apps do not. Third, copy the note's folder to a new location and reopen it in a plain Markdown editor: if the picture still renders, it was a portable file all along. This is the same audit-the-claim discipline that separates a security badge from a security doc.

Frequently asked questions

These are the questions people type when an image breaks or an export leaves a hole where a picture should be. The pattern behind every answer is the same: find out which of the four storage models your app uses, and the behavior stops being a mystery.

Where are my images actually stored in Obsidian? As regular files in your vault. Obsidian's help documentation states plainly, "Attachments are regular files that you can access using your file system."² The note holds a relative link to the file, and both live on your own disk. That sidecar model is why Obsidian images survive a folder copy — the picture travels beside the note it belongs to.

Does Notion store images or just link to them? It stores them as server objects and links to them with an expiring URL. Notion's developer reference says a hosted file "includes a temporary public url valid for 1 hour," and warns, "Don't cache or statically reference these URLs."⁸ The image is on Notion's servers, not your device, so the link dies once the note leaves the app.

Will my images come with me if I export or switch note apps? It depends on the storage model. Sidecar apps — Obsidian, Logseq, Joplin, Typora — keep pictures as real files that travel in the folder. Database apps (Bear, Apple Notes) and cloud apps (Notion, Standard Notes) store them elsewhere, so a hand copy misses them; you must run the app's own export, which pulls the images back out.

Are images embedded in the Markdown file or saved separately? Almost always saved separately. A CommonMark image link stores a reference string, not the bytes,¹ so the picture is a distinct file the note points to. The one exception is inline base64, where the image bytes are pasted into the file as text — self-contained, but a third larger and unreadable in a plain editor.¹¹¹²

Where does Bear or Apple Notes keep attachments on disk? Inside a database, not a folder. Bear's FAQ says, "Bear's notes are stored in an SQLite database,"⁶ and your images live inside that single file. Apple Notes uses a NoteStore.sqlite database with a Media/<UUID>/ directory, per forensic analysis — Apple publishes no official doc, so treat that as reverse-engineered.⁷

Why did my images break after I moved my notes? Because the picture is a separate object the note only names. If the note held a relative path and you moved the note without its image folder, the path stops resolving.¹ If the app used a cloud blob, the signed URL simply expired.⁸ The words survived; the reference to the picture did not.

How do I make image links relative so they don't break? Use an app that writes standard ![alt](path) links to a file kept beside the note, and set attachments to save in the same folder. Typora's default already does this — "Copy image files to target folder when inserting local image."⁴ A relative link to a file you own is the one arrangement that survives every future move.

An image is the moment your notes stop being just text and become a filing decision the app makes for you. Know which of the four decisions your app made, and you know whether your pictures are yours to keep or the vendor's to hold.

MNMNOTE keeps your notes as plain Markdown on your own device, works offline, and exports to files you own — you can open a tab and start at mnmnote.com.