Choose localStorage when
- Single-user, single-device state: theme, draft text, a local game save.
- Offline-first behavior or zero network latency requirements.
- Anything where data leaving the device is unacceptable.
TmpState vs localStorage
localStorage is the browser's built-in key-value store: synchronous, zero-dependency, offline, free, and scoped to one origin on one device. For single-user client-side state it is unbeatable, which is why every prototype starts there.
The honest verdict
localStorage is where prototype state begins; TmpState is where it goes when a second device, a second person, or an AI agent enters the picture. The moment you catch yourself wanting to see the same data on your phone, send a demo link with live state, or let an agent inspect what the app stored, you have outgrown the device boundary; that is the actual dividing line, not size limits.
Side by side
| Dimension | TmpState | localStorage |
|---|---|---|
| Scope | Shared: any device, any client, any collaborator or agent holding the URL. | One origin, one browser profile, one device. |
| Setup | One curl to create; fetch() to use. | Zero: it is already in the browser. |
| Offline | No; it is a network service. | Fully offline, synchronous API. |
| Size and shape | Collections of JSON documents, 10 KB per doc, quotas per database. | ~5 MB of strings per origin; you build your own structure. |
| Inspectability | Admin web viewer, __schema, __export; an agent can read state it did not write. | DevTools on that specific device. |
| Durability | 24h free with paid extension/Pro paths; explicit, visible expiry. | Until the user clears site data; silent and per-device. |
| Security model | Capability URL: whoever holds it, has it. Keep it server-side in real apps. | Same-origin policy; data never leaves the device. |
Choose TmpState when
- The same state must appear on a laptop and a phone in the same demo.
- Someone else (a teammate, a tester, an AI agent) needs to read or write the state.
- You want the prototype's data to survive a cleared cache or a fresh browser profile.
- The agent building the app needs to verify real reads and writes happened.
When NOT to use TmpState here
An honest comparison argues against us too. Skip TmpState if any of these apply:
- Do not add a network hop for state that is genuinely single-device; localStorage is faster and simpler.
- Do not put the raw database URL in public client code unless you accept the data being public.
- Latency-sensitive UI state (keystroke-level) belongs in memory or localStorage, synced later.
Common questions
Can I use both?
That is the normal pattern: localStorage for instant local UI state, TmpState as the shared source of truth your app syncs to through its own API routes.
Is TmpState as private as localStorage?
Different model: localStorage never leaves the device; a TmpState database is exactly as private as its URL. Keep the URL server-side and it behaves like a private backend; paste it publicly and the data is public.
Try the ten-second version
The fastest way to compare is to create a database right now. No signup; it expires on its own.