The Innerholm export format.

Layout of the ZIP

innerholm-export.zip
├── Daily/
│   ├── 2026-08-14-Tuesday-and-the-long-walk.md
│   ├── 2026-08-12-untitled.md
│   └── …one file per entry, newest first…
├── Cold-Water/
│   └── 2026-07-30-What-I-want-to-bring-on-Thursday.md
├── 2026-07-11-An-entry-in-no-journal.md
├── photos/
│   ├── 3f2a9c1e-7b4d-4e0a-9d21-5c6f8a0b1d2e.jpeg
│   └── 8c1d0e7f-2a3b-4c5d-8e9f-0a1b2c3d4e5f.png
└── _encrypted-journals-not-included.txt   (only if you have encrypted journals)

File names

Each entry's file is named from the day it was written and its title:

<Journal>/yyyy-MM-dd-<sanitised title>.md

The date is your day, not UTC: the day the app files that entry under in the calendar and in your lists, taken from your device's time zone when you export. An entry written at 6:30pm on 8 August is named for the 8th, even though the instant in the front matter is the 9th in UTC. The title, and the journal name in the folder, are made safe for every file system the same way on every path:

• These characters, and the space, each become a hyphen: < > : " / \ | ? *
• Leading and trailing hyphens are trimmed.
• The result is cut to 80 characters.
• An empty or whitespace-only title becomes untitled, and so does a name made only of dots, which would otherwise read as a path rather than a name.
• A journal named after something the archive already uses (photos, the manifest) gets -journal appended, so its entries cannot land among your images.

So Tuesday, and the long walk written on 14 August 2026 in a journal called Daily becomes Daily/2026-08-14-Tuesday,-and-the-long-walk.md.

No two entries ever share a path. Where a date and title would repeat inside the same folder, the second file takes -2, the third -3, and so on. Two journals may share a name, and they stay separate folders the same way: the second is Daily-2. A ZIP is allowed to hold two members with the same name, but every extractor keeps only one of them, so a duplicate name would mean an entry quietly missing from your backup. The in-browser export used for encrypted and on-device journals counts the same way.

One file, in full

A worked example, exactly as it comes out of the archive:

---
title: "Tuesday, and the long walk"
date: 2026-08-14T21:07:43Z
journal: "Daily"
starred: true
tags: ["walking", "the move"]
---

Out along the river path again, further than last week. The light
was already going by the time I turned back.

![](../photos/3f2a9c1e-7b4d-4e0a-9d21-5c6f8a0b1d2e.jpeg)

Thing to bring on Thursday: the conversation with M. about the
house, and why I keep circling it instead of landing.

Every text file in both archives is UTF-8 with no byte-order mark, so a Markdown file begins on the --- of its front matter and a Day One JSON file begins on its {. Parsers test exactly that, and a stray mark in front of it is the difference between a file that reads and one that does not.

Front matter

Between two --- lines, always in this order:

Nothing else appears in the front matter. There is no id, no mood, no updated. See "what is not in it" for why we say so plainly.

Body

After the closing --- comes one blank line, then the entry. Paragraphs are separated by a blank line and line breaks are kept. Three things are written as real Markdown, because they are content rather than styling:

• Links keep their address: [fares & passes](https://example.com/fares), or the bare URL when the link text was already the URL. An address you deliberately kept is not something a backup may drop.
• Checklists keep their boxes: - [x] lift the garlic for a ticked item, - [ ] cut back the ferns for an untouched one, one per line.
• Tables keep their grid, as a standard pipe table with a header row and a | --- | separator under it. A table's meaning is which value sits under which heading, so a column of loose words would not be the same writing. Rows are padded to the widest one; a pipe inside a cell is escaped as \|; a merged cell keeps its text in the first column it covers and leaves the rest empty, because a pipe table cannot say "merged". If your table has no header row, an empty one is written above it rather than promoting your first row of writing into a heading you did not write.

The rest of the rich formatting inside an entry (bold, headings, ordinary lists) is flattened to its text; it is not rewritten as Markdown syntax. What you wrote is all there, greppable, in the order you wrote it. The body has no trailing newline.

Images

An image placed inline in an entry becomes a standard Markdown image link on its own line, ![](../photos/<attachment id>.<ext>), at the position it held in the text. The ../ climbs out of the journal folder to the shared photos/ at the root; an entry that sits at the root links to photos/… directly. Every referenced image file is written once into photos/, even if two entries reference the same picture. If an image file cannot be read at export time, the entry still exports and the link is left in place; the archive never fails because of one blob. There is no alt text, because the editor does not collect any.

Order and scope

• Every entry in every ordinary journal, newest first Files are added to the archive by creation date, descending. Most tools list a folder alphabetically, which puts the date-prefixed names in chronological order anyway.
• A journal you keep with someone else comes out whole Both people's pages are in it, together in the one journal folder, exactly as the app shows them to you. Neither format marks who wrote which page, because the app does not either: a shared journal is one book. If a sharing has ended, that journal's pages are no longer yours to export, the same way they are no longer yours to read.
• Entries you have deleted are not included An entry you let go waits 30 days under Settings, Privacy, “Entries you let go”, where you can bring it back, and is then purged. It is left out of the export for as long as it is waiting.
• End-to-end encrypted journals are not in the server export Our servers cannot read them, so they cannot write them into this file. The manifest names each one. Open the encrypted journal, unlock it, and use Export inside it: the browser builds the same files, byte for byte, from your own decrypted copy, and names the journal in each one's front matter. Being one journal, they sit at the root of their own ZIP rather than in a folder. On-device journals export the same way, from the device they live on.
• Everything else on the account is included Every journal, every tag, every inline image the server holds.

What is not in it (and we would rather say)

• Mood, weather, and other practice marks. Not exported in either format today.
• Most rich formatting as Markdown syntax. Bold, headings and ordinary lists are flattened, not converted. The words survive; the bold does not. Links, checklists and tables are the exceptions, above.
• Journals kept on this device, and end-to-end encrypted ones. Not in the account export, because the server cannot read either. Encrypted journals are named in the manifest; both export from inside the journal itself, in the same format.
• Who wrote which page of a shared journal. There is no byline in the app, so there is none in the file. The journal comes out whole, both hands, as one book.
• PDF. Not an archive format, and deliberately not one. The two archives are the Markdown ZIP and the Day One ZIP, and they are free because a journal you cannot get back is not private, it is trapped. There is a typeset PDF, the keepsake: one journal over a stretch of days, set as a book to keep (Innerholm+). It is craft rather than portability, so it is not what you would use to leave, and nothing about it makes the two free archives smaller.

Any of these could be added later without breaking a file exported today: new front-matter keys are additive, and a reader that ignores unknown keys keeps working. If the format changes in a way that matters, this page changes with it.

The Day One-compatible ZIP

The second export, innerholm-day-one.zip, is shaped for Day One's JSON import. It holds one JSON file per journal, named after the journal (Cold-Water.json), which is the shape Day One's own export takes, so your journals arrive as journals rather than in one heap. Entries that belong to no journal go to Journal.json, the name Day One gives its default. Each file holds an entries array (each entry with its uuid, text, creationDate, modifiedDate, starred, tags, and a photos list), and a shared photos/ folder holds the image files, referenced by identifier and MD5 as Day One expects. The text field is Markdown, so links, checklists and tables survive there too. It carries the same entries as the Markdown export, in the same order, and it leaves out encrypted journals the same way, with the same manifest. Use it if you are moving to Day One; use the Markdown ZIP for everything else.

Why this format

• Open Markdown, YAML front matter, and ZIP are all published, unowned formats with readers on every platform. Nothing here needs Innerholm to open.
• Greppable One entry per file, plain text inside. grep -l "the move" *.md finds every entry about the move. A shell, a text editor, or a search tool is a complete reader.
• Importable The front-matter shape is the one Obsidian, Zettlr, Logseq, and most static-site tools already understand. Drop the folder into a vault and the titles, dates, and tags are metadata on arrival.
• Boring, on purpose No custom container, no binary blob, no schema version to keep up with. A file exported today will read the same in twenty years, which is the whole point of writing things down.