For anyone interested in reading more about it, Stack Overflow user kangax has written an incredibly in-depth blog post about the delete statement on their blog, Understanding delete. It is highly recommended.

An upshot of one of the observations at the "understanding delete" link above, is that, since you cannot necessarily delete a variable, but only object properties, you therefore cannot delete an object property "by reference" -- var value=obj['prop']; delete value //doesn't work
– George JemptyApr 16 '10 at 16:24

15

So it doesn't actually delete it? It just becomes undefined, but the key still exists? Am I missing something?
– Doug MolineuxAug 10 '11 at 2:21

@ChristopherPfohl works for me. Like I said, it's actually quite in-depth, so it's a bit difficult to summarize. The basic response in the answer above is sufficient for almost all cases, the blog goes into some more of the edge cases and the reasons those cases exist.
– nickfDec 20 '12 at 1:57

Operator delete is unexpectedly slow!

Delete is the only true way to remove object's properties without any leftovers, but it works ~ 100 times slower,
compared to its "alternative", setting object[key] = undefined.

This alternative is not the correct answer to this question! But, if you use it with care, you can dramatically speed up some algorithms. If you are using delete in loops and you have problems with performance, read the verbose explanation.

When should one use delete and when set value to undefined ?

An object may be seen as a set of key-value pairs. What I call a 'value' is a primitive or a reference to other object, connected to that 'key'.

Use delete, when you are passing the result object to the code on which you don't have control (or when you are not sure about your team or yourself).

It deletes the key from the hashmap.

var obj = {
field: 1
};
delete obj.field;

Use setting to undefined, when you care about performance. It can give a serious boost to your code.

The key remains on its place in the hashmap, only the value is replaced with undefined. Understand, that for..in loop will still iterate over that key.

Beware Of Memory Leaks!

While using obj[prop] = undefined is faster than doing delete obj[prop], another important consideration is that obj[prop] = undefined may not always be appropriate. delete obj[prop] removes prop from obj and erases it from memory whereas obj[prop] = undefined simply sets the value of prop to undefined which leaves prop still in memory. Therefore, in circumstances where there are many keys being created and deleted, using obj[prop] = undefined can force expensive memory reconciliation (causing the page to freeze up) and potentially an out-of-memory error. Examine the following code.

In the code above, simply doing nodeRecords[i][lastTime] = undefined; will cause a massive memory leak because each animation frame. Each frame, all 65536 DOM elements will take up another 65536 individual slots, but the previous 65536 slots will only be set to undefined which leaves them hanging in the memory. Go ahead, try to run the above code in the console and see for yourself. After forcing an out-of-memory error, attempt to run it again except with the following version of the code that uses the delete operator instead.

As seen in the above code snippet, there are some rare appropriate use cases for the delete operator. However, do not worry about this problem too much. This will only become a problem with long-lifespan objects that get new keys constantly added to them. In any other case (which is almost every case in real-world programming), it is most appropriate to use obj[prop] = undefined. The main purpose of this section is just to bring this to your attention so that in the rare chance that this does become a problem in your code, then you can more easily understand the problem and thus not have to waste hours dissecting your code to locate and understand this problem.

Do Not Always Set To undefined

One aspect of Javascript that is important to consider is polymorphism. Polymorphism is when assigning the same variable/slot-in-an-object different types as seen below.

However, there are two major unfixable problems with polymorphic arrays:

They are slow & memory inefficient. When accessing a specific index, instead of just getting the global type for the array, the browser instead has to get the type on a per-index basis whereby each index stores the additional metadata of its type.

Once polymorphic, always polymorphic. When an array is made polymorphic, the polymorphism cannot be undone in Webkit browsers. So, even if you restore a polymorphic array to being non-polymorphic, it will still be stored by the browser as a polymorphic array.

One may liken polymorphism to a drug addiction. At first glance, it seems awesomely lucrative: nice pretty fluffy code. Then, the coder introduces their array to the drug of polymorphism. Instantly, the polymorphic array becomes less efficient, and it can never become as efficient as it was before since it is drugged. To correlate such circumstance to real life, someone on cocaine might not even be capable of operating a simple door handle, much less be able to calculate digits of PI. Likewise, an array on the drug of polymorphism cannot ever be as efficient as a monomorphic array.

But, how does a drug trip analogy relate to the delete operation? The answer inheres the last line of code in the snippet above. Thus let it be reexamined, this time with a twist.

var bar = ["Some", "example"];
bar[2] = "text"; // bar is not a polymorphic array here because all its entries have the
// same type: string primitive
bar[1] = ""; // bar is still a monomorphic array
bar[1] = undefined; // bar is now a polymorphic array

Observe. bar[1] = "" does not coerce polymorphism whereas bar[1] = undefined does. Therefore, one should always, whenever possible use the corresponding type for their objects so as to not accidentally cause polymorphism. One such person may use the following list as a general reference to get them going. However, please do not explicitly use the below ideas. Instead, use whatever works well for your code.

When using an array/variable typed to the boolean primitive, use either false or undefined as the empty value. While avoiding unnecessary polymorphism is good, rewriting all your code to explicitly forbid it will likely actually result in a decrease in performance. Use common judgement!

When using an array/variable typed to the number primitive, use 0 as the empty value. Note that internally, there are two types of numbers: fast integers (2147483647 to -2147483648 inclusive) and slow floating point doubles (anything other than that including NaN and Infinity). When an integer is demoted to a double, it cannot be promoted back to an integer.

When using an array/variable typed to the string primitive, use "" as the empty value.

When using a Symbol, wait, why are you using a Symbol?!?! Symbols are bad juju for performance. Everything programmed to use Symbols can be reprogrammed to not use Symbols, resulting in a faster code without Symbols. Symbols are really just super inefficient meta-sugar.

When using anything else, use null.

However, be mindful! Do not suddenly start doing this with all your preexisting code now as it would likely break such preexisting code and/or introduce strange bugs. Rather, such an efficient practice needs to be implemented from the start, and when converting preexisting code, it is recommended that you double, triple, quadruple check all the lines relating to that as trying to upgrade old code to this new practice can be as risky as it is rewarding.

a property is assigned to undefined still is a property of an object, so it will not be removed by GC, unless misread your last paragraph.
– LanceMar 4 '14 at 21:05

7

I was wrong to touch the theme of GC here. Both methods have the same result for GC: they remove the value linked to the key. If that value was the last reference to some other object, that object would be cleaned up.
– DanMar 6 '14 at 10:28

10

a property is assigned to undefined still is a property of an object, so it will not be removed by GC The GC doesn't manage anything about properties. It collects and removes values. As long as nothing references a value (an object, string, etc.) anymore, the GC does remove it from memory.
– meandreJul 16 '14 at 15:03

7

BTW, that is the dual problem to check if a property exist on Javascript object. Using in operator is the reliable but slow. Check if the property is not undefined "is not the correct answer" but it is a way faster. check
– rdllopesNov 3 '14 at 17:32

3

Is this answer still relevant? jsperf is currently down, but this benchmark seems to indicate that the speed difference is a mere 25%, which is nowhere close to the "~ 100 times slower" in this answer.
– CerbrusDec 14 '16 at 8:29

Update 2018-07-21: For a long time, I have felt embarrassed about this answer, so I think it's time that I touch it up a little bit. Just a little commentary, clarification, and formatting to help expedite the reading of the needlessly long and convoluted parts of this answer.

As you can see, delete doesn't always work as one might expect. The value is overwritten, but the memory is not reallocated. That is to say, array[4] isn't relocated to array[3]. Which is in contrast to Array.prototype.unshift, which inserts an element in the beginning of the array and shifts everything up (array[0] becomes array[1], etc.)

Honestly, aside from setting to null rather than undefined--which is legitimately weird--this behavior shouldn't be surprising, since delete is an unary operator, like typeof, that is hard-boiled into the language and is not supposed to care about the type of object it's being used on, whereas Array is a subclass of Object with methods specifically designed for working with arrays. So there's no good reason for delete to have a special case cooked in for re-shifting the array, as that would just slow things down with unnecessary work. In retrospect, my expectations were unrealistic.

Of course, it did surprise me. Because I wrote this to justify my crusade against "null garbage":

Ignoring the dangers and problems inherent in null, and the space wasted, this can be problematic if the array needs to be precise.

Which is a terrible justification for getting rid of the nulls--null is only dangerous if used improperly, and it has nothing to do with "precision". The real reason you shouldn't delete from an array is because leaving garbage-filled and messy data structures around is sloppy and bug-prone.

What follows is a contrived scenario that gets pretty long-winded, so you can skip to the section, The Solution, if you want. The only reason I leave this section in is because I think some people probably think it's funny, and I don't want to be "that guy" who posts a "funny" answer and then deletes all the "funny" from it later on.

...It's stupid, I know.

The contrived and long-winded PDP-11 scenario

For example, say you are creating a webapp that uses JSON-serialization to store an array used for 'tabs' in a string (in this case, localStorage). Let's also say that the code uses the numerical indices of the array's members to "title" them when drawing to the screen. Why are you doing this rather than just storing the "title" as well? Because... reasons.

Okay, let's just say that you're trying to save memory at the request of this one user who runs a PDP-11 minicomputer from the 1960's running UNIX, and wrote his own Elinks-based, JavaScript-compliant, line-printer-friendly browser because X11 is out of the question.

Increasingly stupid edge-case scenario aside, using delete on said array will result in null polluting the array, and probably causing bugs in the app later on. And if you check for null, it would straight up skip the numbers resulting in the tabs being rendered like [1] [2] [4] [5] ....

Now, you could keep a second iterator, like j, to increment only when valid values are read from the array. But that wouldn't exactly solve the null issue, and you still have to please that troll PDP-11 user. Alas, his computer just doesn't have enough memory to hold that last integer (don't ask how he manages to handle a variable-width array...).

And just like that, you've pleased Mr. PDP-11. Hooray! (I'd still tell him off, though...)

Array.prototype.splice vs Array.prototype.slice

I feel it's important to point out the difference between these two similarly-named functions, as they are both very useful.

Array.prototype.splice(start, n)

.splice() mutates the array, and returns the removed indices. The array is sliced starting from the index, start, and n elements are sliced out. If n is unspecified, the entire array after start is sliced out (n = array.length - start).

Array.prototype.slice(start, end)

.slice() is non-destructive and returns a new array containing the indicated indices from start to end. If end is left unspecified, the behavior is the same as .splice() (end = array.length). The behavior is a bit tricky since, for some reason, end indexes from 1 instead of 0. I don't know why it does this, but that's how it is. Also, if end <= start, the result is an empty array.

The index specified by end is simply excluded from the slice. The parenthesized indices indicate what gets sliced. Either way, the behavior is not intuitive and it's bound to cause its fair share of off-by-one errors, so you might find it useful to make a wrapper function to more closely emulate the behavior of .splice():

Note that the wrapper function is designed to be very strict about types, and will return null if anything is off. That includes putting in a string like "3". It is left up to the programmer to be diligent about his types. This is to encourage good programming practice.

So as it turns out, there actually IS a built-in way to tell if an array is truly an array, and that is Array.isArray(), introduced in ECMAScript 5 (December 2009). I found this while looking to see if there was a question asking about telling arrays from objects, to see if there was either a better solution than mine, or to add mine if there were none. So, if you're using a version of JavaScript that is earlier than ECMA 5, there's your polyfill. However, I strongly recommend against using my is_array() function, as continuing to support old versions of JavaScript means continuing to support the old browsers that implement them, which means encouraging the use of insecure software and putting users at risk for malware. So please, use Array.isArray(). Use let and const. Use the new features that get added to the language. Don't use vendor prefixes. Delete that IE polyfill crap from your website. Delete that XHTML <!CDATA[[... crap, too--we moved to HTML5 back in 2014. The sooner everybody withdraws support for those old/esoteric browsers, the sooner the browser vendors will actually follow the web standard and embrace the new technology, and the sooner we can move on to a more secure web.

This delete keyword, however, is much more convenient, lol
– Braden BestSep 18 '12 at 0:59

11

This approach doesn't modify the original object which might be still referenced elsewhere. This might or might not be a problem depending on how it's used but it's something to keep in mind.
– Tamas CzinegeNov 7 '12 at 17:39

17

@B1KMusic Here's the way to delete an element from an Array: splice
– wulftoneJan 25 '13 at 20:20

2

@wulftone nope, that splits the array and does nothing to delete a value. I really think the best way to delete from an array where specific values are needed to be deleted is to use delete and make a Garbage Collection function to clean it up.
– Braden BestJan 26 '13 at 20:37

Maybe because the goal is to remove a property from an object, not to create a new one without the property... although, your solution is my favorite, as I prefer the immutable way.
– Vingt_centimesDec 1 '16 at 17:14

6

The question stated "to end up with new myObject".
– Koen.Dec 1 '16 at 20:45

1

This is actually a sweet one-liner for new object assignment without unwanted props, and already supported with Node.js 8.*/9.* with --harmony: node.green/…
– Damaged OrganicJul 1 '17 at 18:51

1

@PranayKumar I was hoping this syntax would work; const { [key], ...newObject } = myObject; but it doesn't, so I don't think it's possible with destructuring.
– Koen.May 3 at 11:06

The term you have used in your question title Remove a property from a JavaScript object, can be interpreted in some different ways. The one is to remove it for whole the memory and the list of object keys or the other is just to remove it from your object. As it has been mentioned in some other answers, the delete keyword is the main part. Let's say you have your object like:

Then even if you remove it from your object myJSONObject, that specific object won't get deleted from the memory, since the regex variable and myOtherObject["regex"] still have their values. Then how could we remove the object from the memory for sure?

The answer would be to delete all the references you have in your code, pointed to that very object and also not use var statements to create new references to that object. This last point regarding var statements, is one of the most crucial issues that we are usually faced with, because using var statements would prevent the created object from getting removed.

Which means in this case you won't be able to remove that object because you have created the regex variable via a var statement, and if you do:

delete regex; //False

The result would be false, which means that your delete statement haven't been executed as you expected. But if you had not created that variable before, and you only had myOtherObject["regex"] as your last existing reference, you could have done this just by removing it like:

myOtherObject["regex"] = null;
delete myOtherObject["regex"];

In other words, a JavaScript object gets killed as soon as there is no reference left in your code pointed to that object.

Update:
Thanks to @AgentME:

Setting a property to null before deleting it doesn't accomplish
anything (unless the object has been sealed by Object.seal and the
delete fails. That's not usually the case unless you specifically
try).

You're wrong - only objects are passed by reference in JavaScript, so if myJSONObject.regex's value is a string and you assign it to some other object, the other object has a copy of this value.
– Michał PerłakowskiJan 10 '16 at 16:58

You are right and this is a quote: "to be careful about your other references to the same object."
– Mehran HatamiJan 10 '16 at 17:34

Note

While you technically can use delete for an array, using it would result in getting incorrect results when calling for example Hogwarts.staff.length later on. In other words, delete would remove the element, but it wouldn't update the value of length property. Using delete would also mess up your indexing.

So, when deleting values from an object, always first consider whether you're dealing with object properties or whether you're dealing with array values, and choose the appropriate strategy based on that.

If you want to experiment with this, you can use this Fiddle as a starting point.

Object.freeze() makes all properties of object not configurable (besides other things). deleteProperty function (as well as delete operator) returns false when tries to delete any of it's properties. If property is configurable it returns true, even if property does not exist.

The difference between delete and deleteProperty is when using strict mode:

@Gothdo it has more benefits, especially when you need to do some functional stuff. E.g. you can assign function to variable, pass as an argument or use apply, call, bind functions...
– madox2Jan 10 '16 at 16:47

Delete Operator
Readable and short, however it might not be the best choice if you are operating on a large number of objects as its performance is not optimized.

delete obj[key];

Reassignment
More than 2X faster than delete, however the property is not deleted and can be iterated.

obj[key] = null;
obj[key] = false;
obj[key] = undefined;

Spread Operator
This ES6 operator allows us to return a brand new object, excluding any properties, without mutating the existing object. The downside is that it has the worse performance out of the above and not suggested to be used when you need to remove many properties at a time.

This post is very old and I find it very helpful so I decided to share the unset function I wrote in case someone else see this post and think why it's not so simple as it in PHP unset function.

The reason for writing this new unset function, is to keep the index of all other variables in this hash_map. Look at the following example, and see how the index of "test2" did not change after removing a value from the hash_map.

Due to the dynamic nature of JavaScript there are often cases where you simply don't know if the property exists or not. Checking if obj exists before the && also makes sure you don't throw an error due to calling the hasOwnProperty() function on an undefined object.

Sorry if this didn't add to your specific use case but I believe this to be a good design to adapt when managing objects and their properties.

delete foo.bar works even if bar doesn't exist, so your test is a bit too much, IMHO.
– PhiLhoJun 1 '15 at 15:14

@PhiLho that depends on where you are running JavaScript. In Node.js I believe this causes your server to crash.
– WillemJun 2 '15 at 20:07

2

delete foo.bar; only throws an exception if foo is falsy, or if you're in strict mode and foo is an object with an unconfigurable bar property.
– MacilJun 2 '15 at 21:28

I don't remember the exact issue I've had with this but I think the problem may appear when foo itself doesn't exist and you try to delete it's property.
– WillemJun 2 '15 at 22:20

Yes, you have to test if foo exists, otherwise foo.bar will throw an exception, but you don't need to check the existence for bar before deleting it. That's the "too much" part of my comment. :-)
– PhiLhoJun 3 '15 at 9:16

Using delete method is the best way to do that, as per MDN description, the delete operator removes a property from an object. So you can simply write:

delete myObject.regex;
// OR
delete myObject['regex'];

The delete operator removes a given property from an object. On
successful deletion, it will return true, else false will be returned.
However, it is important to consider the following scenarios:

If the property which you are trying to delete does not exist, delete
will not have any effect and will return true

If a property with the same name exists on the object's prototype
chain, then, after deletion, the object will use the property from the
prototype chain (in other words, delete only has an effect on own
properties).

Any property declared with var cannot be deleted from the global scope
or from a function's scope.

As such, delete cannot delete any functions in the global scope (whether this is part from a function definition or a function (expression).

Functions which are part of an object (apart from the
global scope) can be deleted with delete.

Any property declared with let or const cannot be deleted from the scope within which they were defined. Non-configurable properties cannot be removed. This includes properties of built-in objects like Math, Array, Object and properties that are created as non-configurable with methods like Object.defineProperty().

This function works like a charm, but why do we need return true and return false? My version of the code: codepen.io/anon/pen/rwbppY. Will my version fail for any case?
– novemberskyJul 17 '17 at 0:07

@witty2017 it won't fail. The place where I used the function also needed to check whether the property already exists or not. if the property doesn't exist, it'll return false. If it finds the property and deletes it, it'll return true.
– ayushgpJul 17 '17 at 5:52

Try it with a modern browser such as Firefox, Chromium or Safari. And I expect it to work with Edge as well.
– ideaboxerApr 3 at 20:45

As an alternative, if your customers force you to support outdated browsers, you could consider using TypeScript which transpiles your code into legacy syntax (+ gives you the benefit of static type safety).
– ideaboxerApr 3 at 20:48

Property Removal in JavaScript

There are many different options presented on this page, not because most of the options are wrong—or because the answers are duplicates—but because the appropriate technique depends on the situation you're in and the goals of the tasks you and/or you team are trying to fulfill. To answer you question unequivocally, one needs to know:

The version of ECMAScript you're targeting

The range of object types you want to remove properties on and the type of property names you need to be able to omit (Strings only? Symbols? Weak references mapped from arbitrary objects? These have all been types of property pointers in JavaScript for years now)

The programming ethos/patterns you and your team use. Do you favor functional approaches and mutation is verboten on your team, or do you employ wild west mutative object-oriented techniques?

Are you looking to achieve this in pure JavaScript or are you willing & able to use a 3rd-party library?

Once those four queries have been answered, there are essentially four categories of "property removal" in JavaScript to chose from in order to meet your goals. They are:

Mutative object property deletion, unsafe

This category is for operating on object literals or object instances when you want to retain/continue to use the original reference and aren't using stateless functional principles in your code. An example piece of syntax in this category:

This category is the oldest, most straightforward & most widely supported category of property removal. It supports Symbol & array indexes in addition to strings and works in every version of JavaScript except for the very first release. However, it's mutative which violates some programming principles and has performance implications. It also can result in uncaught exceptions when used on non-configurable properties in strict mode.

Rest-based string property omission

This category is for operating on plain object or array instances in newer ECMAScript flavors when a non-mutative approach is desired and you don't need to account for Symbol keys:

Mutative object property deletion, safe

This category is for operating on object literals or object instances when you want to retain/continue to use the original reference while guarding against exceptions being thrown on unconfigurable properties:

In addition, while mutating objects in-place isn't stateless, you can use the functional nature of Reflect.deleteProperty to do partial application and other functional techniques that aren't possible with delete statements.

Syntax-based string property omission

This category is for operating on plain object or array instances in newer ECMAScript flavors when a non-mutative approach is desired and you don't need to account for Symbol keys:

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).