ViewState Explained

ViewState is the mechanism ASP.NET Web Forms uses to preserve a page's control values across postbacks despite HTTP being fundamentally stateless. After a control's properties change during processing, the page serializes those changes into a base64-encoded string and embeds it in a hidden field named __VIEWSTATE inside the rendered <form>; on the next postback, ASP.NET reads that field back and restores each control's state before Page_Load runs, which is how, for example, a Label's text set in code-behind survives a subsequent postback without you re-setting it manually.

Each control that participates in ViewState stores its tracked property changes in a StateBag, a dictionary-like structure, and the Page's SavePageStateToPersistenceMedium method (invoked around SaveStateComplete) walks the entire control tree, aggregates each control's StateBag via SaveViewState, and serializes the result — historically using the LosFormatter, an optimized binary serializer — before base64-encoding it into the __VIEWSTATE field. On the following request, LoadViewState reverses the process: the string is decoded, deserialized, and each control's StateBag is repopulated before its LoadViewState method restores individual properties, all of which happens before Page_Load fires.

The EnableViewState property, settable at both the page and individual control level, controls whether that scope participates in ViewState at all; setting it to false on a read-only Label or a large GridView that never needs to remember its state across a postback can substantially reduce the size of the rendered page, since __VIEWSTATE for a data-heavy grid can easily balloon to tens of kilobytes of base64 text sent with every single response. The trade-off is real: too little ViewState and controls lose their state unexpectedly after a postback, too much and every page load and postback pays a bandwidth and serialization tax, so tuning EnableViewState selectively on non-interactive display controls is a standard Web Forms performance technique.

ViewState is scoped to a single page and a single user, round-tripped through the client on every request, which distinguishes it from Session state (server-side, per-user, persists across multiple pages until it expires or the session ends), Cookies (client-side, can persist across visits entirely), and ControlState (a smaller, always-on subset of state a control author can mark as essential, immune to EnableViewState being turned off, used for things like a GridView's current page index). Choosing the right mechanism matters: putting a large object into Session bloats server memory across all users, while relying on ViewState for data that must survive across different pages simply won't work, since ViewState never leaves the current page.