Introduction

In ASP.NET Web Forms, an asp:Button normally triggers a postback to the server when it is clicked. That behavior is useful for server-side events, but it is the wrong choice when the button should only run client-side JavaScript or behave like a plain browser button. The clean fix depends on whether you still need a server control or whether an ordinary HTML button is better.

Why asp:Button Posts Back by Default

System.Web.UI.WebControls.Button is a server control. When the page is rendered, ASP.NET wires it so the click submits the form and sends the request back to the server. That is what enables a server-side handler such as OnClick="SaveButton_Click".

If you want no server round-trip, then you should question whether asp:Button is the right control at all. In many cases, a plain HTML button is simpler and more correct.

Option 1: Cancel the Postback with OnClientClick

If you must keep the asp:Button, the usual approach is to return false from the client-side click handler. Returning false tells the browser not to continue with the submit behavior.

1<asp:Button
2    ID="PreviewButton"
3    runat="server"
4    Text="Preview"
5    OnClientClick="showPreview(); return false;" />
6
7<script type="text/javascript">
8function showPreview() {
9    alert("Preview opened without postback.");
10}
11</script>

This is the most common answer because it preserves the server control while preventing the round-trip.

Important detail: return false; must be part of the final expression. If your JavaScript runs but you forget the return, the page will still post back.

Option 2: Use a Plain HTML Button Instead

If there is no server-side event and no server-control behavior is required, use a plain HTML button. That is usually the better design because it matches the intended behavior directly.

1<button type="button" onclick="showPreview()">Preview</button>
2
3<script type="text/javascript">
4function showPreview() {
5    alert("Plain HTML button, no postback.");
6}
7</script>

This avoids the Web Forms lifecycle entirely. It is simpler, easier to reason about, and avoids confusing future maintainers who might expect a server event from an asp:Button.

Option 3: Disable Validation if Validation Is the Real Problem

Sometimes developers say they want to "disable postback" when the real issue is validation. If the click should still go to the server but should not trigger validators, set CausesValidation="false".

1<asp:Button
2    ID="CancelButton"
3    runat="server"
4    Text="Cancel"
5    CausesValidation="false"
6    OnClick="CancelButton_Click" />

This still posts back. It only skips validator execution. Use it when you want a server event without validation, not when you want no round-trip.

Option 4: Prevent Submit in a Reusable JavaScript Handler

For more complex pages, you may prefer a named JavaScript function that returns a boolean. That keeps markup cleaner and allows conditions.

1<asp:Button
2    ID="SearchButton"
3    runat="server"
4    Text="Search"
5    OnClientClick="return handleSearchClick();" />
6
7<script type="text/javascript">
8function handleSearchClick() {
9    const term = document.getElementById("searchBox").value.trim();
10
11    if (term.length === 0) {
12        alert("Enter a search term first.");
13        return false;
14    }
15
16    console.log("Client-side search logic only.");
17    return false;
18}
19</script>

This pattern is useful when the decision to post back depends on browser-side state.

When You Should Not Suppress Postback

If the button exists to save data, run server-side validation, or update server state, suppressing postback is the wrong fix. In that case, keep the postback and optimize the user experience another way, such as:

• using UpdatePanel in legacy Web Forms applications
• reducing server-side work
• moving non-essential UI logic to JavaScript

Suppressing postback on a button that is meant to persist state can create subtle bugs because the UI appears to work while nothing actually reaches the server.

A Small Working Example

This page shows both approaches together.

1<%@ Page Language="C#" AutoEventWireup="true" %>
2
3<!DOCTYPE html>
4<html>
5<head runat="server">
6    <title>No Postback Demo</title>
7    <script type="text/javascript">
8    function showMessage() {
9        document.getElementById("result").innerText = "Client-side action only.";
10        return false;
11    }
12    </script>
13</head>
14<body>
15    <form id="form1" runat="server">
16        <asp:Button
17            ID="ClientOnlyButton"
18            runat="server"
19            Text="ASP Button Without Postback"
20            OnClientClick="return showMessage();" />
21
22        <button type="button" onclick="showMessage()">HTML Button</button>
23        <div id="result"></div>
24    </form>
25</body>
26</html>

Both buttons avoid a server round-trip, but the HTML button expresses intent more clearly.

Common Pitfalls

One common mistake is writing JavaScript in OnClientClick but forgetting return false;. The client code runs, then the form still submits.

Another mistake is using CausesValidation="false" and expecting that to suppress postback. It does not. It only disables validation.

Developers also keep asp:Button when a plain HTML button is sufficient. That adds server-control complexity for no benefit.

Finally, some pages rely on server-side state changes and then disable postback to "fix" flicker. That hides the actual design issue instead of solving it.

Summary

• 'asp:Button posts back by default because it is a server control.'
• Use OnClientClick="...; return false;" when you must keep the server control but prevent submission.
• Prefer a plain HTML button when no server-side behavior is needed.
• 'CausesValidation="false" does not disable postback.'
• Choose the control that matches the real behavior instead of fighting the Web Forms lifecycle.