A knowledge base with double-bracket links, backlinks and tags, kept in this browser, with the storage limit shown and a refused save reported rather than losing the note.
Initializing in your browser…
Write SEO, Open Graph and X card tags with every value escaped for an attribute, checked against the protocol, and the cut shown per platform.
Build a favicon from text, an emoji or an image and get a real favicon.ico holding 16, 32 and 48 pixel images, seven PNGs, a web app manifest and the head tags, in one archive, with the ICO parsed back from its own bytes before it is offered
Tasks with priorities, due dates and tags, kept in this browser, with a full store, a second tab and a document written by an older version all handled instead of losing the list.
You are building a network of linked atomic notes and want the connections to be navigable, not buried in a folder tree.
A note you write
Title: Spaced repetition Body: Works because retrieval strengthens memory. See [[Active recall]] and [[Forgetting curve]].
What the system builds
Note "Spaced repetition" links → Active recall, Forgetting curve Backlinks panel on "Active recall" now shows ← Spaced repetition Graph view connects the three notes
The Zettelkasten method favours many small, single-idea notes connected by explicit `[[wikilinks]]` over deep hierarchies. Typing a link automatically creates the reverse "backlink" on the target note, so knowledge accretes as a navigable graph, everything stored locally in your browser.
A personal knowledge base with double-bracket links, backlinks and tags, kept in this browser. The saving is the part that was rebuilt: a full store, a second tab and a document written by an older version are all handled and said out loud instead of losing your notes.
The three tools on this site that keep a document in your browser (this one, the checklist creator and the Zettelkasten notes) all carried the same four faults before September 2026, and each was measured rather than reasoned about.
**A full store took the tool off the page.** `localStorage.setItem` throws `QuotaExceededError`, and an exception out of a React effect body reaches the nearest error boundary. Driven with the setter made to throw, all three tools vanished from the page and none of them said anything: the write was lost and the work on screen went with it. Now a failed write leaves the change on screen and puts the reason where the person who made it can see it, including how much room is left.
**Every page load wrote an empty document first.** The save effect ran on mount with the state still empty, before the load effect update had rendered. Measured in a production build, the writes on load were `[]` and then the real document, in that order, so there was a window on every single load in which your whole document was an empty array in storage. (In development it was worse than a window: React strict mode double-invokes effects, the empty save landed between the two runs of the load effect, and a seeded item was simply gone after one reload.) The document is now read in the state initialiser, so nothing is ever written before it has been read.
**A second tab silently destroyed the first tab work.** Each write replaces the whole document from the writing tab own state, and nothing listened for the `storage` event. Measured: tab one wrote two items, tab two, opened when there was one, wrote its own, and storage was left holding one. Now each tab is told when another one changes the document and is offered the choice, rather than one of them losing quietly.
**`JSON.parse` succeeding is not validation.** A document written by an older version parses perfectly and then throws on the first field that is read. Every record is now checked field by field: what can be repaired is repaired and the page says what it did, what cannot be read is left alone rather than overwritten, and an imported file goes through exactly the same check as the stored one.
This is the tool where the storage limit matters most, because notes are text and text is what fills a store. The page shows how much of the roughly five mebibytes a browser gives one site the notes are using, and warns before it becomes a refused save rather than after.
A stored note whose tags field is a string rather than a list loads with no tags and a note saying it was written by a different version and has been filled in, instead of throwing when the page tries to map over them.
The storage behaviour is what decides whether that is possible, and it is the part that was rebuilt.
The backlinks panel shows what points at the note you are reading, which is the whole point of the method.
Export the JSON. Everything is in one file with the links intact.
In this browser, under this site, in localStorage. They are not sent anywhere, which also means they are not backed up and are not on your other devices. Export the JSON, and do it often.
A browser gives one site roughly 5 MB of localStorage, counted in UTF-16 code units, so about two and a half million characters of ordinary text. The page shows how much you are using and warns past seventy percent. Beyond that a save is refused, and the page tells you rather than losing the note silently.
That was the old behaviour: both tabs wrote the whole document and the last one won. Now each tab is told when the other changes it and you choose which version to keep.
The link is by name, so it stops resolving until the text is updated. The backlinks panel is where you will notice.
Yes. So will a private window, and so will some settings that block site data. Export the JSON.
This runs as client-side JavaScript. Keys, tokens, payloads, and other inputs never leave your device.