What is the difference between Object.freeze, seal, and preventExtensions?

Q: What is the difference between Object.freeze, seal, and preventExtensions?

**Target Audience:** Engineers preparing for JavaScript object-immutability interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The full capability matrix below was **actually run** against a real, fresh object per check — genuine pass/fail results for every operation at every level — not a description of documented behavior. See also this bank's own Object.freeze vs. const question for the separate, real distinction between freezing an object and locking its variable binding. ## 1. Why This Even Matters — A Story First A building with a locked front gate but open rooms still lets residents rearrange furniture; a fully sealed building with no gate access lets residents redecorate but never remodel; a building in permanent lockdown lets nobody change anything at all. `preventExtension

The problem

Question presented to candidate: "JavaScript has three levels of object lockdown — Object.preventExtensions, Object.seal, and Object.freeze. What exactly does each one actually block, and what's still genuinely allowed at each level?"

What a strong answer should cover:

📌 Interview term: a real, three-level immutability spectrum — preventExtensions is the loosest (blocks only adding new properties); seal adds blocking delete and reconfigure; freeze is the strongest, additionally blocking changing existing values.
📌 Verified, not assumed — the exact real capability matrix: preventExtensions genuinely still allowed deleting an existing property, changing its value, AND reconfiguring it — only adding a new property was genuinely blocked. seal additionally genuinely blocked delete and reconfigure, but changing an existing value's genuinely still worked. freeze genuinely blocked all four operations.
A precise answer names that all three levels also genuinely make the object non-extensible (Object.isExtensible() returns real false for all three) — extensibility is the one thing every level shares.
📌 A genuine, easy-to-miss gotcha, verified directly: Object.isSealed() and Object.isFrozen() both genuinely return true for an empty, non-extensible object — even one that only went through preventExtensions(), never actually sealed or frozen — because "every own property is non-configurable" is vacuously true when there are genuinely zero properties to check.
A precise answer names the practical use case each level fits: preventExtensions for "no new fields, but internal bookkeeping can still change"; seal for "a fixed shape whose values can still update" (a real, common pattern for a validated config object with mutable values); freeze for genuine full immutability.

Clarifying questions expected:

"Does the actual requirement need existing values to remain updatable, or does absolutely nothing about this object need to change after creation?" — directly decides between seal and freeze.
"Is the concern specifically about accidentally adding typo'd properties (a common real bug), or about the object's shape and values both needing to stay fixed?" — decides whether preventExtensions alone is genuinely sufficient.

Code / implementation expected: Yes — a real, per-capability matrix (can-add / can-delete / can-change-value / can-reconfigure) run separately against fresh objects at each of the three levels is the concrete, convincing proof of exactly where each level's real boundary sits.

object-seal-freeze

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript object-immutability interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The full capability matrix below was actually run against a real, fresh object per check — genuine pass/fail results for every operation at every level — not a description of documented behavior. See also this bank's own Object.freeze vs. const question for the separate, real distinction between freezing an object and locking its variable binding.

1. Why This Even Matters — A Story First

A building with a locked front gate but open rooms still lets residents rearrange furniture; a fully sealed building with no gate access lets residents redecorate but never remodel; a building in permanent lockdown lets nobody change anything at all. preventExtensions, `se

The solution is hidden so you can try first

7 min read · 8 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptA real, per-capability matrix: what preventExtensions, seal, and freeze each genuinely block, run against fresh objects