Your Reading Highlights Are Trapped: How to Own Every Annotation as Plain Text

The most durable way to own your reading highlights is to keep them as plain Markdown — one file per book, in a folder you control. Not in a reader app that can die. Not behind a publisher copy cap. Not in a paid hub that exports a snapshot and stops updating. A plain text file outlives all three, and you can search it, diff it, and feed it to your own AI.

Highlights are the strangest thing you own. You wrote them. You chose every sentence worth keeping, across years of reading. They are the most distilled layer of everything you have read — and the least portable. The text you bought sits behind digital locks; the words you selected from it sit in silos that cap copying, hand back a one-way snapshot, or vanish when an app shuts down.

This post is a tool-agnostic system for getting them out and keeping them yours — Kindle, ebook, or PDF, in a format no single vendor controls.

Why highlights are different from bookmarks

A bookmark points at something. A highlight is something. When you save a link, you save an address that someone else still hosts; when you highlight a passage, you create a small original artifact — your judgment about which sentence mattered. That makes highlights the highest-value, least-replaceable layer of your reading, and the one most worth owning outright.

We have argued the web-clipping version before. Capture the text, not the bookmark covers articles and link rot. This piece is the books, ebooks, and PDF sibling — the annotation-and-export layer, where the lock is not a dead URL but a copy cap and a closed format.

Steph Ango, who runs Obsidian, put the principle plainly: "In the fullness of time, the files you create are more important than the tools you use to create them. Apps are ephemeral, but your files have a chance to last."¹ Your highlights are files you create. Treat them that way and they survive every reader you will ever use.

The three trap shapes

Highlight lock-in comes in three shapes, and naming them is half the fix. DRM caps limit how much of a book you can copy. One-way exports hand you a snapshot that never updates. Silo databases hold your annotations in an app that can change terms or shut down. The plain-Markdown move defeats all three at once.

The villain is never a specific company — it is the shape of the lock. Kindle is the clearest example of a cap, Readwise the clearest example of a snapshot, and a discontinued reader app the clearest example of a silo. Each is a useful tool; each leaves your highlights somewhere you do not fully control. Below, each trap, with the documented mechanic.

Trap 1 — the publisher copy cap

On Kindle, how much of a book you can highlight or copy is not your decision and not even Amazon's alone. "Publishers set a copy limit, usually 5-10% of the book's total content," and "once you've highlighted or copied that much text, Kindle blocks all further text selection," per a TextMuncher analysis of the limit.² Hit the wall and the highlighter simply stops working.

It got tighter. By late 2025, "Copying from My Notebook in the Kindle app became restricted for many titles," and "the publisher's copy limit now applies to Notebook exports too" — closing a path readers had used to get their annotations out.² The cap that once lived only in the reader spread to the export.

The backup door narrowed too. Amazon told users that "Starting February 26, 2025, the 'Download & Transfer via USB' option will no longer be available" for purchased Kindle books, as reported by VICE.³ The simplest way to keep a local copy of what you bought ended on a fixed date — a reminder that the terms around your reading can change without your consent.

One honest qualifier matters here. There is no flat "10% rule." As TextMuncher notes, "the copy limit is a publisher-controlled percentage or threshold that varies by title, and Amazon does not publish per-book figures."⁴ Some books allow generous excerpts; some block copying after a few sentences. Treat the cap as real but variable, not a law.

Trap 2 — the one-way export snapshot

A paid highlight hub looks like ownership and is not quite. It aggregates your highlights and exports them to Markdown — but the export is a snapshot. Readwise's own documentation is explicit: "If you edit highlights (or add notes/tags) in Readwise to highlights that have already been exported, those changes will not propagate to your note-taking app."⁵

The reasoning is sound — "This is to ensure that none of your notes are accidentally overwritten,"⁶ the docs explain — but the consequence is the point. The living copy lives in the hub's database; the file you hold is a frozen print of one moment. That is not a flaw in any one product. It is what an export is. The lesson is to make the exported file the canonical one, then keep editing that.

Trap 3 — the silo that can disappear

The third trap needs no villain at all. A reader app holds your annotations in its own database, and one day the company changes its terms or its prices or its lights. We wrote the read-later version of this — the read-later pile is a graveyard. The highlight version is worse: what dies with the app is your own distilled thinking. A file in a folder has no shutdown date.

The durable move: a plain-Markdown file per source

Here is the whole system in one sentence: for every book, ebook, or PDF you annotate, keep one plain-Markdown file of your excerpts and your own notes, in a folder you control, normalized so the text survives copying. That file is searchable forever, diffable across edits, readable in any editor, and feedable to an AI you run yourself.

Plain text is the format Ango means when he writes that lasting artifacts "must be files you can control, in formats that are easy to retrieve and read."¹ Markdown is exactly that: human-readable, machine-parseable, supported by every editor that will ever exist. A .txt or .md file from 2004 still opens today. No reader app can make that promise.

The payoff compounds. Once a few years of reading live as plain files, you can grep across every highlight you ever took, and link a passage in one book to its contradiction in another. Point a local or bring-your-own-key AI at the folder and ask questions across your whole reading history — see a personal RAG you can actually audit. That works only because the highlights are open text first.

The five-minute version

The fast path recovers the highlights you already have and gets them into a file you own. Five steps, no special tooling beyond a text editor.

1. Find the device file. Every highlight on a Kindle is written to a plain-text file on the device. Plug the Kindle in over USB and look in the documents/ folder for My Clippings.txt — it is already human-readable.⁷
2. Copy it off. Drag My Clippings.txt to your computer. This is the part that survives even the copy cap, because the cap governs selecting text in the reader, not the file the device already wrote.
3. Pull cloud highlights too. For Amazon-purchased books, open your Kindle Notebook and copy the highlights the export still allows — these are the ones the cap may limit, so take what you can.
4. Normalize the text. Kindle clippings carry curly quotes and other non-ASCII marks that can turn to garbage on a careless paste. Open the file in an editor that reads UTF-8 and fix the encoding before you trust it; the deep "why" is in what plain text actually means.
5. Split into one file per book. Paste each book's highlights into its own .md file, titled with the book name. That is the unit you will search and edit forever.

That is the recovery pass. The thirty-minute version turns it into a habit.

The thirty-minute version

The expanded workflow makes the file the place you actually think, not just a dump. Same five steps, plus the editing that makes a highlight worth keeping. Budget thirty minutes per book you finish.

• Start from the recovered file. Open the per-book .md you created above. Every raw highlight is already in it.
• Add your own words under each excerpt. Below every passage, write one line on why you kept it. The excerpt is the author's; the note is yours, and the note is what you will reread.
• Tag the connections. When a highlight echoes another book, add a [[wiki-link]] or a tag. Plain Markdown supports both, and the links cost nothing.
• Keep the file canonical. From now on, edit this file, not a hub's database. If you also use a paid hub, treat its export as a one-time seed, then let the plain file lead.
• Back it up like it matters. It is text, so it fits anywhere — a synced folder, a git repo, a drive. Diff it over time and you can watch your own reading change.

The robertmartin8/KindleClippings utility (196 stars, MIT-licensed, last updated May 2025) automates the parse: as its author describes it, the tool "fetches any highlights that you have made on your kindle, and organises them into plain text files per book."⁷ Use it or do it by hand — the output is the same, and the output is the point.

A worked shape of the per-book file looks like this:

# Thinking, Fast and Slow — Daniel Kahneman

> "Nothing in life is as important as you think it is, while you are thinking about it."
— my note: the focusing illusion; tag #attention, echoes [[Deep Work]]

> "A reliable way to make people believe in falsehoods is frequent repetition."
— my note: why repeated claims feel true even when sourced once

Two parts, every entry: the author's excerpt as a blockquote, your own note underneath. The excerpt is theirs; the note is what you will actually reread. The file is yours.

Common mistakes

Most highlight-ownership efforts fail in the same few ways. Each is avoidable once named.

• Trusting My Clippings.txt as a complete history. It is device-local and partial. For Amazon-purchased books your highlights sync to Amazon's cloud, but for sideloaded or emailed files they live only in this file — and deleting a highlight does not reliably reset the copy cap. Treat the file as a recovery path, not a full archive.
• Stating the cap as a flat 10% law. It is publisher-set and varies by title.⁴ Plan for the wall, but do not quote a number that is not universal.
• Capturing the whole book. Copyright limits wholesale full-text capture. Own your excerpts and your own words, not a pirated copy of the text. The move is to keep your distilled annotation layer, not to rip the book.
• Letting a hub stay canonical. If the living copy lives in someone else's database, you own a snapshot, not the highlights. Make the plain file the source of truth.
• Skipping the encoding fix. Curly quotes and stray marks will mojibake on a naive paste. Normalize once on import and the file stays clean.

How this works in a plain-text editor

Once your highlights are Markdown, the natural home is any editor that treats your files as yours. A local-first one stores the notes on your own device, reads them offline, searches them as plain text, and — when you want to share — encrypts the share end-to-end without an account in between. Because the files are open Markdown, nothing is locked to the editor.

That is the whole pitch for MNMNOTE in this context: it is a place to keep the files, not another silo to keep them in. Your highlights stay plain text you could open in any other tool tomorrow. If you want to ask questions across years of reading, a bring-your-own-key setup lets you point your own AI at the folder. The ownership is in the format; the editor is just where you read.

Frequently Asked Questions

What is the Kindle clipping limit? It is a publisher-set copy cap, usually 5-10% of a book, enforced by Amazon across surfaces. "Publishers set a copy limit, usually 5-10% of the book's total content," and once reached, "Kindle blocks all further text selection."² The exact figure varies by title — Amazon publishes no per-book number.⁴

How much Kindle text can I copy? There is no universal amount. The limit is "a publisher-controlled percentage or threshold that varies by title, and Amazon does not publish per-book figures."⁴ Some books allow generous excerpts; some stop you after a few sentences. Recover what you can, and lean on the device file for the rest.

Does deleting Kindle highlights reset the copy limit? Usually no. The cap tracks how much of a title has been copied, and removing individual highlights does not reliably restore it. Plan around the wall instead — pull your highlights early, and keep the My Clippings.txt file, which the reader's selection cap does not govern.

Where is the My Clippings.txt file and can I get my highlights off the device? Yes. Every highlight on a Kindle is written to My Clippings.txt in the device's documents/ folder — plain text you can copy over USB.⁷ It is the most reliable recovery path, especially when the in-app copy cap blocks selection.

Do my Kindle highlights sync if I sideloaded the book or it is a PDF? No. For sideloaded or emailed documents, your highlights live only in the device's My Clippings.txt and do not sync to Amazon's cloud the way purchased-book highlights do. That makes copying the file off the device the only way to preserve them.

Doesn't a paid highlight hub already own my highlights for me? It holds them and can export them, but the export is one-way. "If you edit highlights (or add notes/tags) in Readwise to highlights that have already been exported, those changes will not propagate to your note-taking app."⁵ A hub gives you a snapshot; the durable copy is the plain file you hold and keep editing.

Is exporting my own highlights legal? Keeping your own excerpts and notes for personal use is ordinary fair use; ripping a book's full text is not. The system here is about owning your distilled annotation layer — your selected passages plus your own words — never wholesale capture of the work.

The text you read belongs to its author. The judgment about which sentences mattered belongs to you — so keep it where no cap, no snapshot, and no shutdown can reach it.

This builds on Steph Ango's "file over app" principle — to keep your highlights as files that outlast any reader, mnmnote.com holds them as plain Markdown on your own device.