String primitives have no properties of their own, so why does `'abc'.length` work, and why does assigning `s.foo = 1` to a string variable never stick?

## The apparent contradiction A primitive is a value, not an object: it has no own properties and no place to store any. Yet `'abc'.length` is 3, `'abc'.toUpperCase()` returns `'ABC'`, `(255).toString(16)` returns `'ff'`, and `true.valueOf()` returns `true`. If primitives have nothing on them, where do the property and the method come from? ## Autoboxing: ToObject on property access The answer is that evaluating a property reference whose base is a primitive triggers a conversion. The specification's property-lookup path applies **ToObject** to the base value, which creates a wrapper object of the corresponding type: a `String` object for a string, `Number` for a number, `Boolean` for a boolean, `Symbol` for a symbol, `BigInt` for a bigint. That wrapper holds the primitive in an internal slot, and its prototype is the matching built-in prototype — which is where `toUpperCase`, `toFixed`, `description` and friends actually live. The property is read from the wrapper, and then the wrapper is gone; nothing in the program holds a reference to it. So `'abc'.length` is really: box `'abc'` → read `length` off the temporary `String` object (its own `length` slot, reflecting the UTF-16 code-unit count) → discard. Engines do not literally allocate an object for every character access — this is one of the most heavily optimized paths in any JavaScript engine — but the observable semantics are exactly as described, and the observable part is what interviews probe. ## Why writes disappear Once you see that the wrapper is temporary, the write case follows immediately: ```js let s = 'abc'; s.foo = 1; // creates 'foo' on a throwaway wrapper s.foo; // boxes a BRAND NEW wrapper, which has no 'foo' → undefined ``` Each property access creates its own wrapper. The one that received `foo` was discarded before the second line ran. The variable `s` still holds the primitive `'abc'`; nothing about it changed. This is a favourite interview trap because people expect the assignment either to work or to throw, and in sloppy mode it does neither — it silently evaporates. ## Strict mode makes the failure loud In strict mode the same assignment throws: ```js 'use strict'; let s = 'abc'; s.foo = 1; // TypeError: Cannot create property 'foo' on string 'abc' ``` This matters more than it used to, because ES modules and class bodies are strict mode automatically. Code that silently swallowed the mistake in an old script now throws once it moves into a module. Being able to say *both* behaviours, and name which context you are in, is what separates a complete answer from half of one. ## The `this`-boxing corollary The same conversion applies to the `this` value of a non-strict function. If you add a method to `String.prototype` in a sloppy-mode script and call it on a primitive, `this` inside is the wrapper object, not the string: ```js // in a non-strict script (not a module) String.prototype.kind = function () { return typeof this; }; 'ab'.kind(); // 'object' ``` Add `'use strict'` to the function body — or write the same function inside a module, where strictness is automatic — and `this` stays the primitive, so it returns `'string'`. This bites people who write `this === 'ab'` inside such a method and find it false, or who compare `this` against a string with `switch`. In strict code the primitive is passed through untouched, which is the saner behaviour and the reason the change was made. ## `null` and `undefined` have no wrapper They are the two primitives with no corresponding wrapper type, so ToObject on them fails and property access throws: ```js null.length // TypeError: Cannot read properties of null (reading 'length') undefined.foo // TypeError: Cannot read properties of undefined (reading 'foo') ``` That is the mechanical reason behind the single most common runtime error in JavaScript, and behind the existence of optional chaining as a way to short-circuit before the access happens. ## Practical consequences Three things worth carrying away. First, you cannot tag a primitive with metadata — there is no place to put it; use a `Map` keyed by the value, or carry an object instead. Second, a value's methods coming from a prototype means monkey-patching `String.prototype` affects every string in the realm, and your patch will see a wrapper as `this` unless you write it in strict code. Third, the fact that reads work and writes vanish is asymmetric on purpose: reads have a well-defined result from the prototype chain, while writes have nowhere durable to go.