How to Export and Back Up Reading Highlights from Any Reader App

How to Export Kindle Highlights and Back Up Reading Notes from Any Reader App

Kindle, Apple Books, Google Play Books, Kobo, and PDF/EPUB apps: what actually exports, what gets silently truncated, and how to keep every note you own · 9 min read

The most fragile part of your library

You highlighted a passage in a book you finished three months ago. Today you go looking for it, and the book is gone: the publisher pulled the license, the service shut down, or the account lapsed and took the annotations with it.

Highlights held inside a vendor account are exposed to three failure modes, and the site's own trade-offs piece names them plainly: shutdown, breach, and account loss. Files do not face those risks. As that piece puts it, "Ownership is literal. The library is a set of files you control, which survive an app shutdown, a store delisting, or a subscription change."

This guide is written for heavy highlighters. If the answer to the site's self-check question, do you highlight heavily and need those notes everywhere at once, is yes, you have the most to lose when annotations get trapped, and the most to gain from a portable archive of Markdown and CSV files.

One test closes every section below: can your highlights leave as a file you control? Ask it on Kindle, on Apple Books, on Play Books, and before you commit hours of highlighting to any PDF or EPUB app. Exporting is not a one-time migration. It is an ongoing bridge between whatever you read in today and whatever you will read in next.

How to export Kindle highlights and check what the export missed

A complete-looking Kindle export can quietly be an incomplete one, so Kindle deserves the closest check in this guide.

Publisher-set clipping limits are the trap. When you reach one, Kindle may stop sending new highlights to your export or to any sync service connected to your account, even though the highlights still appear inside the book as you read it. You will believe you have a complete archive. You will not (Textmuncher's export guide).

This matters double if you sync Kindle highlights through a third-party service such as Readwise: the sync inherits the same limits upstream, so a connected account is not the same thing as a complete archive.

Scope is the second trap. Treat any single export as a snapshot of one surface: highlights you made in a different app, or on a different device, may be missing unless they synced to that surface first. Know which surface an export covers before you trust it as complete.

The practical routine:

1. Export on a schedule, not once, and keep every raw dump.
2. Spot-check the file against the book: a passage you can still see in the text should be in the export.
3. Keep raw exports pristine. Merge them in a copy, not in the original.

Apple Books: no export button, so script it

Apple Books has no straightforward highlights export. The workaround is the local SQLite database on the Mac, at ~/Library/Containers/com.apple.iBooksX/Data/Documents/AEAnnotation/, plus an open-source script that reads it.

Scripts such as apple-books-highlights open and close Apple Books first to force a database refresh, then write one Markdown file per book. The book's asset ID and metadata are preserved in a YAML header, and a "My Notes" section survives later runs untouched. That last detail is what turns the export from a one-time dump into a repeatable sync: run it monthly, and each book's file updates without clobbering your own writing.

The asset ID in the frontmatter does quiet work here. It gives each book a stable identity across re-exports, so files dedupe cleanly whether they land in a folder of Markdown or inside a vault like Obsidian.

State the trade-off honestly: the database path is Mac-only. If you annotate on iPhone or iPad, a Mac step belongs in your workflow, because there is no equivalent export from iOS alone (Chapterly's walkthrough).

Google Play Books: the auto-backup that deletes your edits

Google Play Books looks like the easy case. Annotations sync automatically to Google Drive as documents, which creates a false sense of portability: they are already files, in a place you can see. Then you edit one, and the trap springs.

Google's own guidance describes the behavior exactly: "If you edit an annotations document in Drive, the changes you made are deleted when you add more annotations to the same book. To edit and save to a synced document, make a copy of the document first" (Google Play Books support).

So treat the synced Drive documents as a read-only source of truth. The workflow is copy, convert to Markdown or CSV, and never touch the synced original again. Per-collection export and Google Takeout exist as bulk escape hatches, but verify their current limits before relying on them for a full archive.

The lesson generalizes to every platform in this guide: raw exports stay raw, and edited copies live separately.

Kobo, PDF, and EPUB apps: audit export limits before you annotate

Two questions do the audit:

• Do annotations live inside the file itself, or in the app's own database or account silo? An annotated EPUB or PDF that carries its marks in the file travels with the file. Annotations stored in a database travel only as far as the app's export button allows.
• Can the highlights leave as a file you control: Markdown, CSV, or the annotated file itself?

Describe any workaround you find accurately. Flag methods that violate an app's terms of service rather than recommending them blindly. Do not assume conversion will be lossless; it rarely is. And re-verify every documented export path before a big migration, because vendor export UIs change often. Everything in this guide is date-checked for 2026.

If an app offers no export at all, switch early. The longer you stay, the more trapped your notes become, and re-annotating a book costs far more than moving it.

A highlights Markdown export template every app can feed

Platform exports are messy and inconsistent. Normalize them into two shapes and they become app-proof.

One Markdown file per book, with a YAML header:

---
title: "Thinking in Systems"
author: "Donella Meadows"
source: kindle
asset_id: B00ABC123
export_date: 2026-03-14
---

## Highlights

- **Location 214** · 2026-02-02
> The behavior of a system cannot be known by knowing the elements of which the system is made.

- **Location 402** · 2026-02-09
> The least obvious part of the system, its function or purpose, is often a crucial determinant of the system's behavior.

## My Notes

- The leverage-point framing applies to reading habits too.

And one CSV schema for structured use:

title,author,location,highlight,note,date
Thinking in Systems,Donella Meadows,214,"The behavior of a system...","leverage points",2026-02-02

The location column earns its place. A page number or position anchor lets you trace a highlight back to its source even after you switch apps and every book reflows differently. Without it, a highlight is just an orphaned sentence.

The division of labor is simple: Markdown for human reading and for future-proof tools; CSV for spreadsheet review and for migrations between note apps. Keep every raw export pristine and do all editing in copies, the same copy-first rule that protects Play Books users from edit loss.

Once normalized, an exported highlights Markdown file is readable in any focused reader, including SReader, which imports Markdown alongside TXT, EPUB, and PDF text.

Back up reading highlights on a schedule, not just once

A one-time dump is not enough, and the reason is structural. Local-first annotation is per-device: notes made on the iPad live on the iPad.

A structure that survives app switches:

Highlights/
kindle/
apple-books/
play-books/
pdf-epub/
converted/

Drop each raw platform export into its subfolder. Normalize into working copies in converted/. Name files consistently, Author - Title plus an export date, so repeat exports never collide or overwrite. Always keep the unedited raw dump of each run.

This is also where local-first honesty belongs. Local-first is no silver bullet; as RxDB's analysis of local-first architecture warns, it "introduces tricky distributed-data challenges like conflict resolution and schema migrations on client devices." A simple export habit sidesteps most of that complexity. The store is plain local files, backed up like any other document, and they survive shutdown, delisting, or a subscription change with no server involved. For more on that trade-off, see The Honest Trade-Offs of Reading Without Cloud Sync.

How to sync highlights to Obsidian without losing your edits

Normalized files feed a knowledge base cleanly, and Obsidian is the common destination. The official Readwise plugin is the instructive case because of one design decision: it is append-only. A highlight from a new book creates a new page in the vault; highlights from an existing book append to the bottom of that page. In Readwise's own words, "Because the Readwise plugin is append-only, nothing in Obsidian will ever be overwritten" (Readwise docs).

That is the payoff for a heavy highlighter: you can edit, link, and rewrite inside your vault forever, and a re-sync will never undo your work.

Sync cadence is your choice: automatically when Obsidian opens, on a 1, 12, or 24-hour interval, or manually from the command palette. One timing caveat: Amazon only pushes Kindle highlights to Readwise a few times a day, so force a resync when you need a same-day capture, and remember the publisher clipping limit still applies upstream.

Structure the vault so highlights become knowledge rather than an archive graveyard. Link each book's highlight page back to its source notes and your book page, then schedule periodic re-review. A highlight you never revisit is a saved link, not a learned idea. If you would rather avoid cloud sync services entirely, plain Markdown import is the universal adapter: the files themselves are the sync. A folder-first approach like the one in Build a Markdown Reading Workflow Without the Clutter works with any note app that reads plain files.

Your annotations should outlive any app

Run the control test one more time, on every app you use today: can your highlights leave as a file you control?

The checklist, in order:

1. Export from each platform, and spot-check that nothing was silently dropped.
2. Normalize to Markdown and CSV, keeping raw dumps pristine.
3. Store locally on a recurring cadence, with dated filenames.
4. Feed the vault, append-only where possible.
5. Re-review on a schedule, so highlights turn into knowledge.

One full-circle move is worth trying: import an exported highlights Markdown file into SReader and re-read your own notes at a controlled pace, with progress saved on the device, no account, and no data leaving your hardware. That is privacy by construction rather than by policy: "files are processed locally with no ads, no accounts, and no data harvesting, so your reading history never becomes a product."

Try SReader.