 <p>There are a few things involved here that it's useful to know.</p> <p>First, <code>.select2("val", xyz)</code> <a href="https://github.com/select2/select2/blob/c24293f2ba3d1de3b2dd1421177d3d91b05be887/src/js/select2/core.js#L462-L470" rel="nofollow">is equivalent to</a> <code>.val(xyz).trigger("change")</code>. The reason why a <code>change</code> event is triggered is for two reasons</p> <ul> <li>Older versions of Select2 used to trigger the <code>change</code> event, so we gave an easy-upgrade path.</li> <li>Other components on the page should be listening to the <code>change</code> event to know when the value of the <code>&lt;select&gt;</code> changes, so it makes sense to trigger it.</li> </ul> <p>Second, Select2 can only know if the underlying value of the <code>&lt;select&gt;</code> changes if you trigger the <code>change</code> event.</p> <p>So when you combine these two issues together, it starts to explain why Select2 doesn't act as you would expect when you set the new value within a <code>change</code> event.</p> <hr> <p>You can get around the cyclic <code>change</code> events by using the <code>select2:select</code> event to determine when a new selection is made, instead of the <code>change</code> event.</p> <p><a href="https://jsfiddle.net/nmeoosLk/8/" rel="nofollow">https://jsfiddle.net/nmeoosLk/8/</a></p> <p>This is locking you into using Select2-specific events, but it's your best alternative if you don't want to always check if the value changed. I personally would recommend not triggering the <code>change</code> event if the value didn't change, as the small amount of code will better help other components understand what is happening on the page.</p>