By RaYell

2009-08-31 11:58:31 8 Comments

When I want to prevent other event handlers from executing after a certain event is fired, I can use one of two techniques. I'll use jQuery in the examples, but this applies to plain-JS as well:

1. event.preventDefault()

$('a').click(function (e) {
    // custom handling here

2. return false

$('a').click(function () {
    // custom handling here
    return false;

Is there any significant difference between those two methods of stopping event propagation?

For me, return false; is simpler, shorter and probably less error prone than executing a method. With the method, you have to remember about correct casing, parenthesis, etc.

Also, I have to define the first parameter in callback to be able to call the method. Perhaps, there are some reasons why I should avoid doing it like this and use preventDefault instead? What's the better way?


@Abdullah Shoaib 2018-02-09 08:14:22

The main difference between return false and event.preventDefault() is that your code below return false will not be executed and in event.preventDefault() case your code will execute after this statement.

When you write return false it do the following things for you behind the scenes.

* Stops callback execution and returns immediately when called.
* event.stopPropagation();
* event.preventDefault();

@Naga Srinu Kapusetti 2013-03-09 19:27:34

I think the best way to do this is to use event.preventDefault() because if some exception is raised in the handler, then the return false statement will be skipped and the behavior will be opposite to what you want.

But if you are sure that the code won't trigger any exceptions, then you can go with any of the method you wish.

If you still want to go with the return false, then you can put your entire handler code in a try catch block like below:

$('a').click(function (e) {
      your code here.........
  return false;

@JAAulde 2011-04-09 18:32:33

Generally, your first option (preventDefault()) is the one to take, but you have to know what context you're in and what your goals are.

Fuel Your Coding has a great article on return false; vs event.preventDefault() vs event.stopPropagation() vs event.stopImmediatePropagation().

NOTE: The Fuel Your Coding link above has been producing 5xx errors for quite some time. I've found a copy of it in the Internet Archive, printed it to PDF, and put it in Dropbox: Archived article on return false; vs event.preventDefault() vs event.stopPropagation() vs event.stopImmediatePropagation() (PDF)

@Visruth 2017-07-29 17:31:41

The reference link is broken, gives 502 error.

@JAAulde 2017-08-02 15:44:54

@VisruthCV See my added note with link to archive version

@James Drinkard 2013-02-19 15:54:37

When using jQuery, return false is doing 3 separate things when you call it:

  1. event.preventDefault();
  2. event.stopPropagation();
  3. Stops callback execution and returns immediately when called.

See jQuery Events: Stop (Mis)Using Return False for more information and examples.

@karim79 2009-08-31 12:05:19

return false from within a jQuery event handler is effectively the same as calling both e.preventDefault and e.stopPropagation on the passed jQuery.Event object.

e.preventDefault() will prevent the default event from occuring, e.stopPropagation() will prevent the event from bubbling up and return false will do both. Note that this behaviour differs from normal (non-jQuery) event handlers, in which, notably, return false does not stop the event from bubbling up.

Source: John Resig

Any benefit to using event.preventDefault() over "return false" to cancel out an href click?

@T.J. Crowder 2011-11-30 13:09:51

return false from a DOM2 handler (addEventListener) does nothing at all (neither prevents the default nor stops bubbling; from a Microsoft DOM2-ish handler (attachEvent), it prevents the default but not bubbling; from a DOM0 handler (onclick="return ..."), it prevents the default (provided you include the return in the attribute) but not bubbling; from a jQuery event handler, it does both, because that's a jQuery thing. Details and live tests here

@BobStein-VisiBone 2013-07-28 14:49:59

It would be helpful to define "Propagation" and "Default" here. I for one keep confusing them. Is this correct? Propagation = my code (JavaScript event handlers for parent elements). Default = browser code (links, text selection, etc.)

@piechuckerr 2016-08-17 10:59:01

what is really mean by bubbling? example?

@Doug S 2016-08-21 02:42:40

+1 for noting that return false does not stop event propagation in non-jQuery event handlers. i.e. <a href="#" onclick="return false">Test</a> does not stop the event from bubbling up.

@Garrett 2010-06-20 21:31:29

This is not, as you've titled it, a "JavaScript" question; it is a question regarding the design of jQuery.

jQuery and the previously linked citation from John Resig (in karim79's message) seem to be the source misunderstanding of how event handlers in general work.

Fact: An event handler that returns false prevents the default action for that event. It does not stop the event propagation. Event handlers have always worked this way, since the old days of Netscape Navigator.

The documentation from MDN explains how return false in an event handler works

What happens in jQuery is not the same as what happens with event handlers. DOM event listeners and MSIE "attached" events are a different matter altogether.

For further reading, see attachEvent on MSDN and the W3C DOM 2 Events documentation.

@rds 2011-01-27 19:49:19

@Garrett 2011-07-24 23:40:02

@rds That says "preventDefault doesn't stop further propagation of the event through the DOM. event.stopPropagation should be used for that."

@Mark Amery 2016-01-24 00:13:43

An answer on a closely-related question alleges that prior to HTML 5, returning false from an event handler wasn't specced as doing anything at all. Now, maybe that's an incorrect interpretation of the (hard to understand) spec, or maybe despite it not being specced literally all the browsers interpreted return false the same as event.preventDefault(). But I dunno; it's enough to make me take this with a pinch of salt.

@Alexander Derck 2016-10-11 21:26:02

I hate how every javascript search result in google is actually about jQuery, +1

@Dilip0165 2014-09-29 11:28:08

My opinion from my experience saying, that it is always better to use


Practically to stop or prevent submit event, whenever we required rather than return false event.preventDefault() works fine.

@Mark Amery 2016-01-23 23:07:38

Better why? You've literally given zero justification whatsoever here. -1.

@Taiger 2017-08-22 22:50:23

In the case there are multiple event bindings, e.preventDefault() is more targeted than return false.

@Joan 2018-03-28 17:25:54

preventDefault is some english words I understand it "prevents the default". return false is some english words I understand it "returns false" but I have no idea why until I Google this cryptic code. And bonus, I can control separatly stopPropagation and preventDefault .

@rahul 2009-08-31 12:04:24

I think


is the w3c specified way of canceling events.

You can read this in the W3C spec on Event cancelation.

Also you can't use return false in every situation. When giving a javascript function in the href attribute and if you return false then the user will be redirected to a page with false string written.

@mplungjan 2012-02-15 12:53:09

Not in any browser I have ever met. Perhaps you confuse that with <a href="javascript:return false" or something?

@Mark Amery 2016-01-23 23:10:47

-1; the claim that a href that returns false will generate a text page with the word "false" written on it is complete nonsense.

@Phil 2017-11-06 16:01:43

(minus)1; broken link + complete nonsense

@Eldar Djafarov 2009-08-31 12:02:31

You can hang a lot of functions on the onClick event for one element. How can you be sure the false one will be the last one to fire? preventDefault on the other hand will definitely prevent only the default behavior of the element.

@Jeff Poulton 2011-01-22 22:37:09

From my experience, there is at least one clear advantage when using event.preventDefault() over using return false. Suppose you are capturing the click event on an anchor tag, otherwise which it would be a big problem if the user were to be navigated away from the current page. If your click handler uses return false to prevent browser navigation, it opens the possibility that the interpreter will not reach the return statement and the browser will proceed to execute the anchor tag's default behavior.

$('a').click(function (e) {
  // custom handling here

  // oops...runtime error...where oh where will the href take me?

  return false;

The benefit to using event.preventDefault() is that you can add this as the first line in the handler, thereby guaranteeing that the anchor's default behavior will not fire, regardless if the last line of the function is not reached (eg. runtime error).

$('a').click(function (e) {

  // custom handling here

  // oops...runtime error, but at least the user isn't navigated away.

@meandmycode 2012-04-27 22:53:23

Whilst true, the opposite behaviour is often preferable when doing progressive enhancement (which I think is probably the most likely reason to be overriding a default action)

Related Questions

Sponsored Content

32 Answered Questions

[SOLVED] How do I return the response from an asynchronous call?

6 Answered Questions

5 Answered Questions

[SOLVED] Explain ExtJS 4 event handling

3 Answered Questions

[SOLVED] event.preventDefault prevents ajax call

8 Answered Questions

[SOLVED] Why does ++[[]][+[]]+[+[]] return the string "10"?

  • 2011-08-26 08:46:14
  • JohnJohnGa
  • 177371 View
  • 1382 Score
  • 8 Answer
  • Tags:   javascript syntax

3 Answered Questions

1 Answered Questions

[SOLVED] JS onClick return false and jQuery global .click

5 Answered Questions

[SOLVED] jQuery Multiple Event Handlers - How to Cancel?

Sponsored Content