View State
View State is the serialized server-side memory of a Visualforce page that travels back and forth between the browser and the Salesforce server on every postback.
Definition
View State is the serialized server-side memory of a Visualforce page that travels back and forth between the browser and the Salesforce server on every postback. It holds every Apex controller variable, every component property, every selectList option, and every form field value that the page needs to remember between user interactions. The platform encodes it into a hidden form field, signs it for tamper protection, and sends it down with the page HTML on the initial render and back up with every form submit.
The size of the View State is capped at 170 KB per page by the platform. When a page exceeds the limit, Salesforce throws a Maximum view state size limit exceeded error and the postback fails. Because View State is the second most common reason a Visualforce page becomes slow or breaks, developers learn to inspect and trim it as a routine part of building any page that holds collections, large strings, or repeated subqueries.
How View State works, why it bloats, and what to cut first when it does
The 170 KB ceiling
Salesforce caps the encoded View State at 170 KB per Visualforce page. The limit applies after compression, so the raw object graph that produces a 170 KB encoded payload is often 500 KB to 1 MB of in-memory Apex state. The most common cause of an exceeded limit is a list of SObjects on the controller that grows as the user scrolls or paginates. A standard list controller helps because it serializes only the current page worth of records, but a custom controller holding every row in a member variable will hit the ceiling fast.
What goes into View State
Every non-transient instance variable on every controller and extension associated with a page goes into the View State. So do the rendered form components, the component tree, and any selectOptions lists. Static variables do not, because they live for the request lifetime only. Apex sObject collections, big strings, blob attachments held in memory, Map and Set objects with thousands of entries, are the four typical bloat sources. Transient lists are also excluded, so the transient keyword is the cheapest tool in the optimizer's box.
Inspecting view state with the developer console
Visualforce includes a built-in View State inspector you reach via the URL parameter ?core.apexpages.devmode.url=1, or by checking Development Mode on the user profile. The inspector shows the size of every node in the serialized graph, sorted descending, so you can see exactly which variable consumes the budget. A common shock for new developers is seeing the Standard Component Tree node take 40 to 60 KB on a page with dynamic visibility; the tree gets re-serialized even when the variables on it are small.
The transient keyword
Marking an Apex instance variable transient excludes it from View State. The variable lives only for the duration of one request and gets recomputed on the next postback. This is the right call for any derived data the controller can rebuild from the database faster than the platform can serialize, ship, and deserialize the cached copy. A typical pattern is to mark a List of wrapper objects transient and rebuild it inside the get accessor on each request. Trade-off is a small extra database hit per page action against a much smaller payload over the wire.
Pagination as a structural fix
The cleanest cure for a list-heavy page is pagination, not optimization. Use StandardSetController, OFFSET in SOQL, or the LimitOffset variant of a custom query, and only keep 20 to 100 records in memory at any one time. Pagination also improves perceived load time because the initial render only has to serialize a small slice, and the next-page request is a fast database read instead of a stitched in-memory operation.
Read-only mode
Visualforce supports a read-only mode declared on the apex:page tag with readOnly="true". It removes the 50,000-row SOQL governor cap (lifts it to 1 million for that page) and trims some View State overhead. It also disables any DML on the page, so it works only for pages that strictly display data. Pair read-only mode with pagination for reports that need to render hundreds of thousands of rows for filtering and export.
Lightning is a different story
View State is a Visualforce concept. Lightning Web Components and Aura do not have a postback model; they use Lightning Data Service caching and explicit Apex method calls to fetch data on demand. The platform still limits payload sizes (Aura @AuraEnabled method responses cap around 10 MB, LWC reactive properties are bound to component lifecycle), but there is no signed serialized form-state envelope traveling back and forth. Most new development should target Lightning Web Components, but legacy Visualforce pages still drive a large amount of customer functionality and the View State limit will be relevant for years.
Diagnose and shrink a View State
Inspect what is in your page View State, identify the largest contributors, and apply the standard fixes (transient, pagination, read-only mode) to bring the page under 170 KB.
- Enable development mode
On your user record, set the Development Mode flag. Open the Visualforce page; a footer at the bottom now exposes the View State inspector link.
- Open the View State inspector
Click the View State tab in the footer. The inspector lists every node in the serialized graph with its byte size, sorted descending. The top three entries are usually where the budget is going.
- Mark large transient candidates
For each controller variable holding a derived list or a large string, add the transient keyword to the field declaration. Recompute it inside the getter so the page still works. Re-run the inspector; the variable should drop to zero.
- Paginate large result sets
Replace the SOQL query that fetched all records with a StandardSetController or an explicit LIMIT/OFFSET. Hold only the current page in memory. Add Next and Previous action buttons that re-execute the query.
- Switch to read-only mode if data is display-only
Add readOnly="true" on the apex:page tag. Confirm no DML operations exist on the page. Re-test to make sure the page still renders.
- Confirm under 170 KB
Re-run the View State inspector. Verify the total is below 170 KB with at least 20 KB of headroom for future data growth.
Field modifier that excludes a controller variable from the serialized View State. Trade-off is the variable is recomputed each postback.
Page-level setting that disables DML, lifts the 50k SOQL row cap to 1M, and trims state overhead.
Built-in controller that paginates large result sets automatically and keeps only one page's records in memory.
Footer-level tool surfaced under Development Mode that breaks down serialized state by node and size.
- Static variables do not contribute to View State, but they also do not persist across requests. Do not use static fields to dodge the limit; the values reset on every postback.
- Marking a variable transient means it is recomputed on every request. If the recomputation costs a SOQL query and that query is now in a loop on a Repeater, you can trade a View State error for a SOQL governor error.
- ApexPages.StandardSetController serializes its own state into View State for navigation. On very large result sets the controller itself can become the bloat source.
- The 170 KB limit is post-compression. A page that shows 165 KB in the inspector is one user action away from blowing through the limit; design with 20 KB headroom.
Trust & references
Cross-checked against the following references.
- View State InspectorSalesforce Developer Docs
- Apex Class Keywords and Modifiers (transient)Salesforce Developer Docs
- Standard List ControllersSalesforce Developer Docs
Straight from the source - Salesforce's reference material on View State.
- Visualforce View StateSalesforce Developer Docs
- Best Practices for Improving Visualforce PerformanceSalesforce Developer Docs
- Platform Limits Cheat SheetSalesforce Developer Docs
Hands-on resources to go deeper on View State.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is View State?
Q2. What's the size limit?
Q3. How do you reduce view state?
Discussion
Loading discussion…