Smarkerapp — How readers capture, tag and retrieve | smarkerapp.com
Where annotations are actually stored, how PDF quad-point and character-offset anchors differ, and which storage quota each browser or app really gives you.
Every highlight you own is stored twice: as content — the quoted text, your note, the tag — and as an anchor, the pointer back into the document. The content is easy to keep; the anchor is what breaks.
PDF anchors are quad points: 8 coordinates per quad describing a rectangle on a specific page. Web anchors in the W3C Web Annotation model are page or character-offset selectors. Offsets count characters, so any layout change — a new edition, a reflow, a regenerated file — moves every offset after the change. That drift is the main maintenance cost of digital highlighting.
On narrow screens, swipe or scroll the plate sideways.
Where the library physically sits matters as much. Browser localStorage holds about 5-10 MB per origin, roughly 5,000 plain-text highlights; IndexedDB is granted tens of megabytes to gigabytes, with Chrome allowing about 60% of free disk. Both are per-origin: clear the profile or the app folds, and the library goes with it.
The durable copy is the export. Three thousand highlights produce roughly 0.5-2 MB of Markdown or PDF against 150-400 KB of plain text, because per-line markup roughly triples the byte count. Export after every session; the file is small enough to keep in any folder, any sync service, any decade.
Scanned documents add weight and fragility at once: a 300 dpi A4 page is about 25 MB uncompressed but 300-500 KB as a 1,500 px JPEG, and the highlight anchors to an OCR layer that is 98-99% accurate on a clean scan but only 85-92% on an angled phone photo. The tagging workflow and the recall method both assume this export exists — it is the piece that makes audits and search cheap.
Further reading