How do you convert a JavaScript Map to a plain object and back, and what does `JSON.stringify(new Map([['a', 1]]))` produce?

## The two conversions A `Map` is an iterable of `[key, value]` pairs, and `Object.entries` produces exactly that shape from an object, so the two directions are one call each: ```js const m = new Map([['a', 1], ['b', 2]]); const obj = Object.fromEntries(m); // { a: 1, b: 2 } const back = new Map(Object.entries(obj)); // Map(2) { 'a' => 1, 'b' => 2 } ``` `Object.fromEntries` (ES2019) accepts *any* iterable of two-element entries, not just a Map, so `Object.fromEntries(pairsArray)` and `Object.fromEntries(url.searchParams)` work the same way. The `Map` constructor is equally liberal: it accepts any iterable of pairs, which is why `new Map(Object.entries(o))` and `new Map(arrayOfPairs)` both work. ## Why JSON.stringify gives `{}` `JSON.stringify` walks an object's own enumerable string-keyed properties. A `Map` has none — its entries live in internal storage reachable only through the Map methods — so the serializer finds an object with nothing to write and emits `'{}'`: ```js JSON.stringify(new Map([['a', 1]])); // '{}' JSON.stringify(new Set([1, 2])); // '{}' — same reason ``` Nothing throws. That silence is what makes it a real production bug: a cache written as JSON, a response body, or a `localStorage` entry becomes an empty object and the loss is only noticed downstream. ## Serializing a Map on purpose Spread the Map into its pair array first, and rebuild from that array on the way in: ```js const m = new Map([['a', 1], ['b', 2]]); const text = JSON.stringify([...m]); // '[["a",1],["b",2]]' const revived = new Map(JSON.parse(text)); // Map(2) { 'a' => 1, 'b' => 2 } ``` This preserves insertion order and, unlike the object route, keeps *string* keys distinct from each other without any coercion surprises — although JSON itself can only carry JSON-representable keys, so numeric keys still come back as numbers only because they were stored inside an array, not as property names. If you would rather the Map serialize itself, give the surrounding value a `toJSON` method, since `JSON.stringify` calls `toJSON` on any value that has one. Defining it on a wrapper object you own is safer than patching `Map.prototype`, which is a global change other code may not expect. Outside JSON, `structuredClone` (available in modern browsers and Node) understands `Map` and `Set` natively and returns a real `Map` with the same entries, including object keys — cloned, not shared. That is the right tool for cloning in memory or posting to a worker; JSON is the wrong tool for anything holding a Map. ## Where the object round-trip loses data `Object.fromEntries` converts each key with the ordinary property-key rules, so anything that is not a string or symbol becomes a string: ```js Object.keys(Object.fromEntries(new Map([[1, 'a']]))); // [ '1' ] — the number became a string const a = { id: 1 }; const b = { id: 2 }; Object.fromEntries(new Map([[a, 'x'], [b, 'y']])); // { '[object Object]': 'y' } — two entries collapsed into one ``` So the object route is lossless only when the keys are already strings. If a Map is keyed by objects or by numbers you care about, convert to the pair array instead, or map the keys to stable ids yourself before converting. Order is preserved in the friendly cases but not guaranteed to survive: a Map iterates in insertion order for all keys, whereas the resulting object visits integer-like keys first in ascending numeric order. A Map keyed `'10'`, `'2'`, `'x'` converts to an object whose keys enumerate as `'2'`, `'10'`, `'x'`. ## What to say in an interview Lead with the two one-liners, then the `'{}'` result and *why* it happens — own enumerable properties versus internal storage — then the pair-array workaround. Mentioning that the conversion is lossy for non-string keys, and that `structuredClone` handles Maps while JSON does not, is what separates a memorised answer from an understood one.