The call localStorage.setItem('user', { id: 1 }) runs without throwing. What is actually stored, and what does localStorage.getItem('missing') return for a key that was never written?

## The interface says string, and it means it The `Storage` interface stores a map of string keys to string values. Both `setItem` arguments go through the normal JavaScript string conversion before they are stored — the same conversion `String(value)` performs. Nothing is rejected and nothing is validated, which is why the call in the question runs happily and produces a value that is useless: ```js localStorage.setItem('user', { id: 1 }); localStorage.getItem('user'); // "[object Object]" ``` The object was converted by its default `toString`, and the property is gone. The same silent flattening happens to every non-string type: ```js localStorage.setItem('n', 42); // stored as "42" localStorage.setItem('ok', true); // stored as "true" localStorage.setItem('nothing', null); // stored as "null" localStorage.setItem('list', [1, 2]); // stored as "1,2" typeof localStorage.getItem('n'); // "string" ``` Arrays are the nastiest of these, because `[1, 2].toString()` is `"1,2"` — plausible-looking text that a reader may mistake for something structured. Keys are converted too, so `setItem(1, 'x')` and `setItem('1', 'x')` write the same entry. ## Serialise on write, parse on read The conventional fix is to serialise structured values yourself before writing and parse them after reading. That makes the round trip explicit, and it also makes the failure modes explicit, which is the part teams skip. ## getItem returns null, not undefined The spec says a read of a key that is not present returns `null`. That is a distinct value from `undefined`, and it matters in three places. First, truthiness checks: `if (localStorage.getItem('flag'))` is `false` both when the key is missing *and* when the stored string is `""`, because the empty string is falsy. If "present but empty" is meaningful in your data, compare against `null` explicitly, or use `key in localStorage`-style checks carefully — note that `Storage` also supports property access (`localStorage.flag`), which returns `undefined` for a missing key rather than `null`, so the two access styles disagree. Prefer the methods and stay consistent. Second, defaults: `const raw = localStorage.getItem('theme') ?? 'light'` works because `??` treats `null` as missing, whereas destructuring defaults (which only fire on `undefined`) do not. Third, and most commonly, the parse step: ```js JSON.parse(localStorage.getItem('missing')); // null — no error ``` That is not a special case in the storage API. The parse argument is converted to a string, `null` becomes the text `"null"`, and `"null"` is valid JSON for the value `null`. So the pattern `const state = JSON.parse(localStorage.getItem(key))` silently yields `null` when the key was never written, and code that then reaches for `state.something` throws a `TypeError` far away from the actual cause. ## Corrupt values do throw The opposite case is a key that holds a string which is not valid JSON — written by an older version of your app, by a browser extension, by a hand edit in devtools, or by a half-finished write. Parsing that throws a `SyntaxError` synchronously. Because the read usually happens during startup or during hydration of a store, an unguarded parse turns one bad key into a blank page. The defensive shape is small and worth writing once: ```js function readJson(key, fallback = null) { const raw = localStorage.getItem(key); if (raw === null) return fallback; try { return JSON.parse(raw); } catch { localStorage.removeItem(key); return fallback; } } ``` Dropping the unreadable key is deliberate: it stops the same failure recurring on every load and frees the space it occupied. ## Consequences for what you persist Because the medium is text and the conversion is yours, persisted values are effectively a versioned format you own. Anything whose runtime type does not survive being written as text and read back has to be reconstructed by hand on read. Shapes change across releases, so a stored entry written months ago by an older build may not match what today's code expects — validating the parsed value against the shape you need, rather than trusting it, is what separates a robust read path from one that throws on a user whose browser has been open since the last deploy. Also note the cost: serialising and parsing happen on the main thread, synchronously, every time. For a small preference that is irrelevant; for a large state blob it is real work in the critical path. ## What interviewers are listening for The short answer — "strings only, so the object is stringified and you get `[object Object]`; missing keys read as `null`" — is table stakes. The stronger answer adds that the conversion is silent, that `null` from a missing key does not make a parse throw, and that a read path in production guards the parse and validates the result.