_.unset() is Lodash’s nested delete helper. You pass an object and a path; Lodash walks to that location and removes the property if it exists. It is the removal counterpart to _.set() and uses the same path syntax as _.get().
💡
Unlike _.omit()
_.omit() drops top-level keys and returns a new object. _.unset() targets nested paths and mutates the object you pass in.
Use it to strip sensitive fields before API responses, remove obsolete config keys, clean dynamic object trees, and delete nested values without fragile delete obj.a.b.c chains that throw when intermediates are missing.
Foundation
📝 Syntax
The signature is two arguments—object and path:
javascript
_.unset(object, path)
Syntax Rules
object — the object to modify (mutated in place).
path — dot string ("address.zip"), array (["profile", "temp"]), or bracket form ("users[0].email").
Return value — true if the property existed and was removed; false otherwise.
Missing paths — no error thrown; the object stays unchanged and you get false.
Parent objects — remain after deletion; empty {} parents are not auto-removed.
javascript
import unset from "lodash/unset";
const user = {
id: 1,
name: "John",
address: { city: "New York", zip: "10001" }
};
unset(user, "address.zip");
// user -> { id: 1, name: "John", address: { city: "New York" } }
For top-level key removal without mutation, prefer _.omit().
Wrap Up
Conclusion
_.unset() is the safe way to delete nested properties without manual delete obj.a.b chains that break when intermediates are missing. Pair it with _.set() for write/delete symmetry and check return values when you need to know whether a key actually existed.
Clone before unsetting when immutability matters. Next in the series: _.update() for applying a function at a nested path.
Use _.has() when you need to confirm a path before deleting
Match path style with _.set() and _.get() across your codebase
Clone before _.unset() when immutability is required
Check the boolean return value when removal success matters
Use _.omit() for shallow, non-mutating key removal
❌ Don’t
Assume _.unset() returns a new object like _.omit()
Expect empty parent objects to be auto-removed after deletion
Confuse _.unset() with immutable delete patterns
Unset paths on shared references without considering side effects
Rely on unset to remove multiple keys—loop or use _.omit() instead
Summary
Key Takeaways
Knowledge Unlocked
Five things to remember about _.unset()
Use these when deleting nested properties safely.
5
Core concepts
🗑️01
Nested delete
Path-based.
Basics
⚠️02
Mutates
In-place removal.
Important
✅03
Boolean
true / false.
Return
🔀04
vs set
Delete / write pair.
Related
🛡️05
Safe path
No throw.
Tip
❓ Frequently Asked Questions
_.unset() removes the property at a nested path on an object. It mutates the object in place and returns true if the property existed and was deleted, or false if the path could not be resolved.
Yes. _.unset() always modifies the object you pass in, just like _.set(). To avoid mutation, clone first: _.unset(_.cloneDeep(obj), path) or work on a copy of your data.
The same formats as _.set() and _.get(): dot-path strings like address.zip, bracket notation like users[0].email, or key arrays like ["profile", "temp"].
Lodash returns false and leaves the object unchanged. Unlike manual delete chains, _.unset() does not throw when intermediate or final segments are missing.
_.omit() removes top-level keys by name and returns a new object. _.unset() deletes at any nested path and mutates the target object in place.
No. After removing a leaf property, parent objects remain—even if they become empty {}. Clean up empty containers separately if your app requires it.
Did you know?
Some older tutorials claim _.unset() is non-mutating and returns a new object—that is incorrect. Like _.set(), it modifies the object you pass in. The return value is a boolean success flag, not a copy of the data.