View State Overview

A Web application is stateless. A new instance of the Web page class is created each time the page is requested from the server. This would ordinarily mean that all information associated with the page and its controls would be lost with each round trip. For example, if a user enters information into a text box on an HTML Web page, that information is sent to the server, but is not returned to the client. To overcome this inherent limitation of Web programming, the ASP.NET page framework includes several state-management features, one of which is view state, to preserve page and control values between round trips to the Web server. For more information on state management, see ASP.NET State Management Overview.

View state is the method that the ASP.NET page framework uses by default to preserve page and control values between round trips. When the HTML for the page is rendered, the current state of the page and values that need to be retained during postback are serialized into base64-encoded strings and output in the view state hidden field or fields. You can change the default behavior and store view state in another location such as a SQL Server database by implementing a custom PageStatePersister class to store page data. For an example of storing page state on a stream rather than in a hidden page field, see the example for the PageStatePersister class.

You can access view state in your own code using the page's ViewState property to preserve data during round trips to the Web server. The ViewState property is a dictionary containing key/value pairs containing the view state data.

Security Note
It is easy for a malicious user to see and modify the contents of a hidden field. For more information on securing view state data, see Securing View State.

For recommendations about when you should store information in view state, see ASP.NET State Management Recommendations.

Data Types You Can Store in View State

You can store objects of the following types in view state:

• Strings

• Integers

• Boolean values

• Array objects

• ArrayList objects

• Hash tables

• Custom type converters (see the TypeConverter class for more information)

You can store other types of data as well, but the class must be compiled with the Serializable attribute so that view state can serialize them into XML.

Considerations for Using View State

View state provides state information for a specific ASP.NET page. If you need to use information on more than one page, or if you need the information to persist across visits to the Web site, you should use another method for maintaining state, such as application state, session state or personalization.

View state information is serialized into XML and then encoded using base64 encoding, which can generate large amounts of data. When the page is posted back to the server, the contents of view state are sent as part of the page post-back information. If view state contains a large amount of information, it can affect performance of the page. Therefore, it is recommended that you test the performance of your pages using typical data for your application to determine if the size of view state is causing performance problems for your application. For alternatives to using view state, see ASP.NET State Management Recommendations.

In some circumstances, such as data-driven pages that are refreshed from the data store on each postback, you should turn view state off to remove the large hidden fields generated by data controls such as the GridView control.

Note
Even when you explicitly turn view state off, a hidden field is still sent to the browser to indicate that postback is occurring for the page.

Another important consideration is that if the amount of data in a hidden field becomes large, some proxies and firewalls will prevent access to the page that contains them. Because the maximum amount can vary with different firewall and proxy implementations, large hidden fields can cause sporadic problems. To help avoid this problem, if the amount of data stored in the ViewState property exceeds the value specified in the page's MaxPageStateFieldLength property, the page splits view state into multiple hidden fields to reduce the size of each individual field below the size that firewalls reject.

Some mobile devices do not allow hidden fields at all. Therefore, view state will not work for those devices. For more information and alternatives, see ASP.NET Mobile Web Development Overview.

Control State

In addition to view state, ASP.NET supports a page-state feature called control state. The page uses control state to persist control information that must be retained between postbacks, even if view state is disabled for the page or for a control. Like view state, control state is stored view state in one or more hidden fields. For more information, see ASP.NET State Management Overview.

See Also

Tasks

How to: Save Values in View State
How to: Read Values from View State

Concepts

ASP.NET State Management Overview
ASP.NET State Management Recommendations