Visualforce view state is the encrypted, hidden copy of a page's components, field values and controller state that Salesforce sends to the browser and back with each form post, so the page remembers where it was between requests. The view state limit is 170 KB per page. To stay under it, mark unneeded variables transient, query fewer rows and fields, and show data read-only where you can.
This guide was first published in 2020 as "Introduction to View State in Salesforce". It has been rewritten for 2026 with a step-by-step diagnosis, the main reduction techniques and how Lightning Web Components handle state instead.
What is view state in Visualforce?
View state is how a Visualforce form page remembers its data between server requests. HTTP is stateless: each request knows nothing about the last one. Visualforce solves this for pages with forms by saving the page's state between requests. According to Salesforce's Optimize the View State guide, the platform stores the state of the page's components, field values and controller as an encrypted string in a hidden form element. That string is the view state.
View state holds, among other things:
- Non-transient instance variables of the page's controller and extensions, including collections of records. Static and transient variables are left out.
- Objects reachable from those variables.
- The component tree of the form and the values of its inputs.
Because the whole string travels with every postback and must be decrypted and deserialized on the server each time, a large view state makes pages slow, and past 170 KB the page fails.
What is the view state limit?
As of November 2026 the limit is 170 KB per page, stated in the Visualforce Developer Guide. Older books and blog posts sometimes give a lower figure; use the current guide. View state is separate from Apex governor limits such as heap size (6 MB synchronous and 12 MB asynchronous, rising to 10 MB and 25 MB from Winter '27, for all orgs from Spring '27), although large collections often push against both. The state of a continuation (asynchronous callout) has its own 80 KB limit.
How to check view state size
Turn on Development Mode with Show View State, then open the View State tab in the page footer.
- Open your personal settings and edit your user details.
- Select Development Mode and Show View State in Development Mode, then save.
- Open the Visualforce page. The development footer now shows a View State tab.
- Expand the folder nodes to see which variables and components take the most space. The Capacity view shows how much of the limit is used and, if the page is over, by how many kilobytes.
Salesforce's development mode footer guide notes two conditions: the tab only appears when the page contains an apex:form tag, and only on pages that use custom controllers or controller extensions. Pages without a form have no view state to inspect. The Developer Console has a View State tab that shows the same breakdown, which helps if the footer disappears after a partial rerender.
How to reduce view state
Store less: mark variables transient, query fewer rows and fields, and show read-only data with output components.
| Technique | What it does | When to use it |
|---|---|---|
Mark variables transient | The variable is not saved in view state | Data needed only for the current request, such as lookup lists rebuilt on each load |
| Filter and paginate queries | Fewer records held in controller variables | Any page that lists records |
| Query only the fields you show | Smaller records in memory and in view state | Always; avoid selecting every field "just in case" |
| Display read-only data with output components | apex:outputText instead of apex:inputField keeps input components out of the form | Fields users don't need to edit |
| Avoid large editable grids | Each editable cell is a component | Tables of hundreds of rows; edit a selected row instead |
| Keep forms small | Only components inside a form contribute input state | Put read-only content outside apex:form |
| Use JavaScript remoting | Calls Apex without a form postback | Highly interactive pages; it improves performance but doesn't shrink the page's view state, and you lose reRender |
| Store IDs, not records | Keep record IDs in state and re-query when needed | Wizards that carry data across steps |
The first four techniques come from Salesforce's view state guide, which also warns that JavaScript remoting does not reduce overall view state, though pages generally perform better with it.
A worked example: the transient keyword
The transient keyword keeps a variable out of view state. A controller that loads a large picklist of reference records on every page load does not need to carry them between requests:
public transient List<Product2> catalogue { get; set; }
Because catalogue is transient, it is rebuilt in the constructor or a getter on each request and never written into view state. Keep only what the user's next action needs, such as the selected product's ID, in normal variables.
Common view state mistakes
Oversized view state almost always comes from holding too much data in controller variables.
- Holding full query results in controller properties. A list of thousands of records with many fields is the usual cause of an oversized view state.
- Wrapping the whole page in one form. Read-only sections inside the form still add components.
- Keeping file contents in a variable. Attachment bodies in controller state fill the limit quickly; clear or mark them transient after upload.
- Multi-step wizards that keep every step's data. Save to the database between steps or keep only IDs.
- Fixing the symptom only. If a page keeps growing past the limit, it may be time to rebuild it, as below.
Visualforce view state vs Lightning Web Components
Lightning Web Components have no view state: state stays in the browser. Lightning Web Components (LWC) work differently. Trailhead's module for Visualforce developers explains that Visualforce uses view state to maintain state between server requests, while in LWC server requests are stateless: the component keeps its state in the browser and each Apex call passes the data it needs.
| Visualforce | Lightning Web Components | |
|---|---|---|
| Where state lives | Server-side controller, carried in view state | In the browser, in the component |
| Size limit | 170 KB view state | No view state; Apex calls are subject to normal governor limits |
| Reading records | Controller queries | Lightning Data Service (preferred) or Apex |
| Repeated server calls | Each postback sends the view state | Cacheable Apex methods avoid repeat calls; cached data may lag recent changes until refreshed |
We have found no retirement date for Visualforce on Salesforce's pages, so existing pages keep working, but new user interfaces are generally built as Lightning web components. If an old page keeps hitting the view state limit, rebuilding it in LWC often fixes the cause rather than the symptom. Our Classic to Lightning migration page and Lightning guide cover the wider move, and our customization guide explains when code is the right tool at all.
Getting help
Techila is a Salesforce Summit Partner. Our Salesforce development services team tunes slow Visualforce pages and rebuilds them as Lightning web components when that is the better fix. Talk to us about a page that keeps hitting the limit.
Frequently asked questions
What is view state in Visualforce?
View state is the state of a Visualforce page, including its components, field values and controller variables, stored as an encrypted string in a hidden form field. It is sent to the browser and back to the server with each form post, so the page keeps its state between requests.
What is the view state limit in Salesforce?
The Visualforce view state limit is 170 KB per page, according to Salesforce's Visualforce Developer Guide. If a page goes over it, the request fails until the view state is reduced.
How do I check the view state size of a Visualforce page?
Turn on Development Mode and the option to show view state in development mode in your personal user settings. Pages that contain an apex:form and use a custom controller or extension then show a View State tab in the development footer, with a Capacity view of how much of the limit is used.
How does the transient keyword reduce view state?
Marking an Apex controller variable as transient keeps it out of the view state, so it is not serialised and sent with the page. Use it for data only needed during the current request, such as query results that are rebuilt on each load.
Do Lightning Web Components have view state?
No. In Lightning Web Components, server requests are stateless and the component keeps its state in the browser. Each Apex call must pass the data it needs, and Lightning Data Service is the preferred way to read and write records.