When your bookmark export won’t import: what we measured
Switching bookmark tools always ends the same way: you export, you upload, and… the importer says “no bookmarks found”, or it imports everything but your folders collapse and your dates vanish. We stopped guessing. We ran real, publicly published export files through a bookmark importer and measured exactly what loads and what breaks. The files, the parser, and the run are reproducible and dated.
Key findings
- 0 of 261. Pocket's real
ril_export.htmlparsed to nothing — it's a<ul>list, not the Netscape format importers read. - 43 of 43. Chrome's HTML export imported perfectly — folders intact, and zero tags (Chrome exports none).
- 306 of 412. A Raindrop export parsed all items, but a description-attachment bug misplaced notes on ~74% of annotated saves — since fixed.
- Dates don't survive. Add-dates were read then discarded at insert — the export file remains the only chronology.
- Failing safe works. Bad files produced a clear error, never a half-imported library.
Method: the deployed parser was copied verbatim into a jsdom harness and run against hash-pinned public exports — node run.mjs reproduces every number. Full protocol: how we test.
The headline: “it’s HTML” is not enough
People assume any .html bookmarks file is interchangeable. It isn’t. There are (at least) two different HTML shapes in the wild, and importers usually only read one of them.
What we tested
We parsed six real export files published publicly by their owners (pinned by SHA-256 so the bytes are unambiguous) through the same Netscape-<DL> parser our product ships. The corpus and hashes are downloadable below — we did not collect anyone’s data; we used files people had already published in their own repos.
| Source app | File type | Items | What the importer did |
|---|---|---|---|
| Chrome (extension export) | Netscape <DL> | 43 | 43/43 parsed. Folders intact; Chrome carries no tags, so none arrived. |
| Raindrop.io (user export) | Netscape <DL> | 412 | 412/412 parsed. But a description-attachment bug mis-set the note on 306/412 (≈74%) of annotated items — since fixed; details below. |
Pocket (official ril_export.html) | UL/LI list, not <DL> | 261 | 0/261 parsed. The file is structurally valid HTML but not the bookmark format the importer reads. It fails safe with “no bookmarks found”. |
| Two mislabeled / corrupt archives | broken HTML | — | 0 bookmarks + a clear validation error. No crash, no half-imported library. |
Sources checked as of Oct 5, 2026: Raindrop’s own import help states it accepts “Pocket — export as HTML file” — which is true for Raindrop’s parser; it is a different importer from ours, and our point is precisely that “HTML” spans multiple incompatible shapes. Firefox’sexport documentationdescribes the Netscape HTML we could read cleanly. We measured only our own importer; we havenot tested whether other vendors fail on the same files, and we don’t claim they do.
Three failures that are easy to miss
- The description landed on the wrong link. Raindrop’s export nests a
<DD>note under each bookmark. Our deployed parser attached some notes to the neighbouring item — 306 of 412 records differed on the description field. A file can “import fine” and still be subtly wrong, which is the worst kind of migration bug because you don’t notice. The fix corrects it for 258/412 records; the rest legitimately have no note. - Original save dates are dropped. The parser does read
ADD_DATE/createdtimestamps — then our insert step discards them, so every imported item takes the import date. The file is your only chronological record. We say this plainly rather than let you discover it: import to Marqly does not preserve save dates. (Raindrop’s own CSV spec, above, showscreatedis importable there — another sign the formats and the tools differ.) - Failing safe is a feature. The 0/261 Pocket-HTML result and the corrupt-archive runs produced “no bookmarks found”, not a partial write. Importers that silently import half a library are more dangerous than ones that refuse.
What this means if you’re moving tools
- If you’re leaving Pocket, don’t hand an importer its
ril_export.htmland assume it worked. Export the archive, findlist.csv, and import that — or preview either file first with our Bookmark File Viewer /Pocket Export Converter. The mechanics are inwhat’s actually in a Pocket export file. - A browser’s Netscape HTML export (Chrome/Edge/Firefox/Safari) is the most portable thing you can carry — it’s the format almost every tool, Marqly included, reads.
- Whatever you choose, keep the export file. Dates and the exact original structure rarely survive a round-trip.
Method & reproducibility
Protocol per our testing standards: the parser under test is a verbatim copy of our production bookmark parser; fixtures are real, publicly published export files (third-party dotfiles and corpora), identified by SHA-256 so the exact bytes are pinned; each item was checked field-by-field (URL, title, tags, description, folder, date) against what the file declared. This is a fidelity test of one importer against real inputs, not a vendor bake-off. We will update this page with a dated change note if the corpus or method changes.
Download the corpus manifest (CSV, SHA-256 pinned)
Want the library this fixes?
Marqly reads the browser HTML export and Pocket’s list.csv, then lets you find any save by meaning with Pro AI semantic search. Guides: migrate from Pocket, migrate from Raindrop, migrate browser bookmarks.
