The tools in this group are local-first, which is a specific technical claim rather than a marketing one. Your notes, flashcard decks, habit streaks, budgets and timer settings are written to the browser's localStorage or IndexedDB on the device you are using. That has real advantages — instant load, no account, no subscription, no server that can go down or change its terms — and it has one consequence people discover the hard way: the data is bound to that browser profile on that machine. It does not follow you to your phone, it does not survive "clear browsing data", and a private-browsing window discards it when the window closes. Anything you would be unhappy to lose is worth exporting.
Timers deserve a technical note, because browser timers are less reliable than they look. When a tab is in the background, browsers deliberately throttle setTimeout and setInterval to fire at most once per second, and after a few minutes of inactivity many will throttle them much harder to save battery. A timer implemented by counting ticks therefore drifts, and can drift badly over a 25-minute Pomodoro. The correct approach — the one used here — is to record a target timestamp when the timer starts and compute the remaining time from the system clock on each update, so throttling affects only how smoothly the display refreshes, never the accuracy of the finish time.
For the QR generator, the error-correction level is the setting worth understanding. QR codes carry Reed-Solomon redundancy at four levels: L recovers from about 7% damage, M about 15%, Q about 25% and H about 30%. Higher levels are what make it possible to sit a logo in the middle of a code and still have it scan, since the covered modules read as damage. The cost is density — the same data at level H needs noticeably more modules than at level L, so the printed code either grows or its individual squares shrink. For a poster scanned from a distance, or any code that might get scuffed, the redundancy is worth the size; for a clean on-screen code, L or M keeps it crisp.
The hardware testers — keyboard, microphone, webcam — use the standard browser input and getUserMedia APIs, which means they are checking the whole chain from the device through the OS driver to the browser. If a key registers here, the hardware and driver are working and the problem is further up in whatever application was dropping it. Camera and microphone access requires an explicit permission prompt, the stream is rendered locally, and nothing is recorded or transmitted unless you press record yourself.
QR error correction levels
Higher redundancy survives more damage but needs a denser code:
| Level | Recoverable damage | Use it for |
|---|---|---|
| L (Low) | ~7% | Clean on-screen codes, long URLs |
| M (Medium) | ~15% | The general-purpose default |
| Q (Quartile) | ~25% | Printed labels, packaging, small logo overlay |
| H (High) | ~30% | Large centred logo, outdoor or industrial use |