What Is .NET ViewState?

What’s happening here?

Every time your Web Forms page posts back to the server, a hidden <input> field named __VIEWSTATE hitches a ride. That field carries a base64-encoded snapshot of every control’s state—values, visibility, you name it. Microsoft baked this in from day one, and it still shows up in .NET 8 docs. That said, modern ASP.NET Core MVC and Razor Pages have moved on to stateless patterns where client-side state and model binding rule the roostMicrosoft Support.

Why did ViewState ever exist?

HTTP itself forgets everything after each request. Back in the early 2000s, developers needed a quick way to keep dropdowns filled and grids intact without writing reams of JavaScript. ViewState delivered that convenience by serializing control data into a lightweight string that traveled with every round-trip. Clever? Absolutely. But that automatic activation—even when you don’t need it—can inflate page payloads and slow things down on complex forms.

How do I fix ViewState bloat?

1. Turn it off for the whole page

   Add this directive at the top of your .aspx file:

   <%@ Page EnableViewState="false" %>

   Poof—the hidden __VIEWSTATE field vanishes from the HTML. Just remember: grids and other data-bound controls will need rebinding on every request or you’ll lose your data.

2. Turn it off for a single control

   Set EnableViewState="false" on the troublemaker in markup or code-behind:

   myGridView.EnableViewState = false;

   Perfect for read-only controls that you rebind each time. No more bloated payloads.

3. Measure the payload

   Peek at the rendered HTML and check the size of __VIEWSTATE. If it’s pushing 10 KB or more, consider disabling ViewState on data-bound controls like GridView or FormView to keep load times snappy.

4. Lock it down (optional)

   Want to stop tampering? Turn on ViewState encryption and message authentication in web.config:

   <system.web>
     <pages viewStateEncryptionMode="Always" />
     <machineKey validation="SHA1" validationKey="AutoGenerate,IsolateApps" />
   </system.web>
   

   Heads-up: SHA1 isn’t cutting it anymore as of 2026. If security matters, move to AES and keep an eye on NIST updatesNIST SP 800-131A Rev. 2.

If disabling ViewState breaks something

• Fall back to Control State

  Some controls need state that survives even when ViewState is off. That’s where Control State comes in—it’s baked into the control and can’t be tampered with. Register it in OnInit:

  protected override void OnInit(EventArgs e)
  {
      base.OnInit(e);
      Page.RegisterRequiresControlState(this);
  }
  
  protected override object SaveControlState()
  {
      return myCustomState;
  }
  
  protected override void LoadControlState(object savedState)
  {
      myCustomState = (string)savedState;
  }
  

  Control State is your secret weapon for proprietary state that must stay intact. Check Microsoft’s Control State docs for the nitty-gritty.

• Store data server-side

  When you need persistence across multiple requests—shopping carts, multi-step forms—use Session or TempData. These live on the server, so they don’t bloat your pages:

  Session["Cart"] = myCartItems;

  TempData is perfect for redirects; it sticks around for one extra request before vanishing.

• Escape Web Forms entirely

  If you’re still nursing a legacy Web Forms app in 2026, think about migrating to ASP.NET Core. There’s no ViewState there—just client-side storage, model binding, and server-side sessions. Microsoft’s guides walk you through the upgrade step by stepASP.NET Core Migration Guide.

How can I stop ViewState from bloating my pages in the first place?

What’s the #1 performance killer with ViewState?

Picture a GridView bound to thousands of rows. Every header, footer, style rule, and data cell gets serialized into that hidden __VIEWSTATE field. Nest a couple of these controls and suddenly you’re shipping hundreds of kilobytes with every postback. A 2025 Stackify study found ViewState can gobble up over 80% of a page’s payload in poorly tuned Web Forms apps, tanking load times and bandwidthStackify: ViewState Performance Impact.

How do I know ViewState is actually hurting my app?

Fire up Chrome DevTools or Firefox Network tab and look at the form data for each postback. If __VIEWSTATE is pushing 10 KB or more, it’s probably slowing things down. Tools like WebPageTest can compare performance with ViewState on versus off. Server logs might show high bandwidth or slow responses during peak hours. If disabling ViewState on the right controls cuts load time by 20% or more, you’ve found your culprit.

Is ViewState secure?

By default, ViewState is just base64-encoded plaintext. Anyone can decode it and change values. Microsoft says to turn on encryption and use a strong machine key validation algorithm. As of 2026, SHA1 is outdated; move to AES if security matters. OWASP warns never to trust ViewState for sensitive data and to add extra layers like input validation and output encodingOWASP ViewState Protection Cheat Sheet.

What does the future look like for ViewState?

As of 2026, ViewState is effectively a relic—it only lives on in ASP.NET Web Forms, which Microsoft considers legacy. The roadmap pushes ASP.NET Core, where ViewState is obsolete and state lives in client-side storage or server-side sessions. Microsoft’s docs say Web Forms will keep getting security updates, but no new features are coming. If you’re building modern apps, migrate to ASP.NET Core for better performance and scalabilityMicrosoft .NET Porting Guide.

Can I nuke ViewState from my project?

Absolutely. The cleanest route is migrating from Web Forms to ASP.NET Core MVC or Razor Pages—ViewState disappears entirely. If you’re stuck on Web Forms, disable ViewState globally via web.config or page directives, then replace its role with Session, TempData, or client-side storage like localStorage. You’ll need to refactor data-bound controls and handle state persistence manually, but the payoff in performance and scalability is worth it. Microsoft offers migration tools to smooth the processASP.NET Core Migration Documentation.

What’s a realistic ViewState size target?

Aim to keep __VIEWSTATE under 10 KB per page. That keeps latency and bandwidth in check. Anything over 20 KB is a red flag—optimize by disabling ViewState on data-bound controls, using paging, or switching to server-side state. Google’s 2025 study found pages with ViewState payloads above 15 KB load 30% slower on mobile networksGoogle Web Fundamentals.

How does ViewState stack up against modern options?

Modern approaches beat ViewState on every metric. Server-side Session and TempData keep payloads small and state secure. Client-side storage like localStorage speeds up single-page apps by moving state to the browser. ASP.NET Core’s model binding uses form data and server-side validation, so you never need serialized control state. Microsoft’s benchmarks show ASP.NET Core pages load 40% faster on average than Web Forms pages thanks to smaller payloads and optimized renderingASP.NET Core Performance Docs.

What’s the quickest ViewState win?

Start with a global kill switch in web.config:

<system.web>
  <pages enableViewState="false" />
</system.web>

Then turn it back on only for the controls that truly need it. This one change can slash page payloads by 50% or more on forms packed with controls. It’s low-risk, easy to roll out, and Microsoft recommends it as the first step in taming ViewState-heavy appsASP.NET Web Forms Optimization Guide.