In TypeScript, what does marking a class member `private` actually prevent, and how is that different from declaring the member as `#name`?

## Two mechanisms, one English word Both `private x` and `#x` are read aloud as "a private field", but they belong to different layers of the stack. `private` is part of TypeScript's **type layer**: a modifier the checker understands and the emitter deletes. `#x` is part of **JavaScript itself** — a private name, which is syntax the engine implements. TypeScript understands `#x` and type-checks it, but it does not own it, and it cannot erase it. ## What the compiler does with `private` During checking, `private` restricts where the member may be referenced: only inside the body of the class that declares it. During emit, the modifier is removed and nothing replaces it. ```ts class Account { private balance = 100; } ``` emits, in essence: ```js class Account { balance = 100; } ``` So the field is a normal own property of the instance. `Object.keys(account)` lists it, `{ ...account }` copies it, `JSON.stringify` serialises it, and a JavaScript consumer of your compiled package writes `account.balance` with no complaint at all. TypeScript never installs a runtime check — that is the whole point of erasure, and it is what makes `private` free. There is one deliberate hole even at compile time: element access with a string literal is exempt from the check, so `account["balance"]` compiles (and is typed as `number`, not `any`). That hatch exists mainly so tests and interop code can reach in without an `any` cast. ## What `#name` is `#balance` declares a *private name*. Private names are lexically scoped to the class body: `other.#balance` is legal inside `Account` and is a compile error anywhere else — TypeScript reports that the private field must be declared in an enclosing class, and a raw JavaScript engine treats it as a syntax error. At run time the field is stored as an internal slot rather than as a property, so it does not appear in `Object.keys`, spread, or `JSON.stringify`. ```ts class Account { #pin = "1234"; matches(other: Account) { return this.#pin === other.#pin; // fine: same class body } } ``` Note that privacy here is per-class, not per-object: one `Account` may read another `Account`'s `#pin`, exactly as it may read another's `private` member. Assuming TypeScript 5.x, the emit depends on `target`: at ES2022 and above the `#` syntax is emitted as written; below that, the compiler downlevels it using WeakMaps to preserve the semantics, which costs a little code size and indirection. ## The differences that matter in an interview 1. **Runtime enforcement.** `private` has none; `#` has real enforcement backed by the engine. 2. **Enumeration and serialisation.** A `private` field is an ordinary property and shows up in logs, spreads and JSON; a `#` field does not. 3. **Escape hatches.** `obj["x"]`, `as any` and plain JS all defeat `private`. Nothing in the language defeats `#`. 4. **Assignability.** `private` and `protected` members make class types compare *nominally*: two classes with identical shapes are mutually assignable only if the private member comes from the same declaration. `#` fields have the same effect on structural compatibility, so both break naive duck typing. 5. **Inheritance.** `private` has a sibling modifier, `protected`, that opens the member to subclasses. Private names have no such tier — a subclass cannot see the base's `#x`. 6. **Declaration output.** A `private` member is still recorded in the generated `.d.ts` (it affects assignability); it is not a secret from consumers of your types. ## Choosing between them Use `private` for ordinary encapsulation inside your own codebase: it is cheaper to write, it is testable through the bracket hatch, and it pairs with `protected`. Reach for `#` when the value must genuinely not leak — credentials, internal handles, anything you do not want in a serialised payload or a log line — or when you publish a class to untyped JavaScript consumers and want the boundary to hold for them too. What you must never say in an interview is that `private` "hides" the value at run time. It hides it from the checker, and that is a code-quality tool, not a security boundary.