Visualforce
Visualforce is Salesforce's legacy UI framework for building custom pages with a tag-based markup language that resembles HTML but renders server-side and integrates tightly with Apex controllers.
Definition
Visualforce is Salesforce's legacy UI framework for building custom pages with a tag-based markup language that resembles HTML but renders server-side and integrates tightly with Apex controllers. Introduced around 2008, Visualforce was the primary way to extend Salesforce's user interface for almost a decade and remains in heavy use in mature orgs. The framework supports custom record pages, list views, wizards, public-facing sites, email templates, and PDF generation, with a rich standard tag library and the ability to define reusable custom components.
Salesforce now recommends Lightning Web Components (LWC) for new UI development, but Visualforce continues to be supported and remains the right tool for several specific scenarios: rich email templates with merge fields and conditional logic, PDF generation via the renderAs attribute, legacy custom pages that have not been migrated, Visualforce-only AppExchange packages, and certain low-trust embedded scenarios where Lightning constraints make LWC harder. Understanding Visualforce remains important for any Salesforce developer maintaining a long-running org because the codebase almost certainly contains Visualforce alongside any newer Lightning components.
The Visualforce framework and its place in the platform
Pages, controllers, and the standard tag library
A Visualforce page is a .page file containing markup wrapped in apex:page tags. The markup uses tags like apex:pageBlock, apex:outputField, apex:inputField, apex:commandButton, apex:repeat, and many more. Standard tags resolve to HTML at render time, with the server doing the work. Each page can have a standard controller (auto-generated from a Salesforce object, providing CRUD operations and save/cancel behavior) or a custom controller (an Apex class with custom logic). Most pages also use a controller extension that adds custom methods on top of the standard controller, giving developers the convenience of the standard while still supporting custom behavior.
Server-side rendering and view state
Visualforce uses a server-side rendering model. Every page request, button click, or form submission triggers a server round trip where the page is re-rendered with the latest data. The page's state between requests is maintained through view state, a serialized snapshot of the controller's instance variables passed back and forth between client and server. The view state is encrypted, base64-encoded, and embedded in the rendered HTML, with a 170 KB size limit. Heavy pages with large data sets can hit the view state limit and require redesign (pagination, transient variables, separate sub-pages) to work around it. The server-side model is fundamentally different from Lightning's client-side reactivity and shapes how developers think about page interaction.
Visualforce in Lightning Experience
Visualforce pages can be embedded in Lightning Experience through several mechanisms: as Lightning Tabs, as Visualforce components inside Lightning page layouts, or as iframes within Lightning App Builder pages. The embedding works but with caveats: the Visualforce page runs in an iframe with the Lightning chrome around it, which can cause styling inconsistencies. Some Visualforce features (Standard Controllers acting on Lightning-specific objects, certain JavaScript libraries) work differently in the Lightning context. Migrating Visualforce pages to LWC removes these inconsistencies but is a non-trivial effort for complex pages.
Visualforce for email templates
Visualforce email templates remain one of the strongest reasons to know the framework. They support rich HTML with merge fields, conditional sections, loops over related records, and calculated content that simpler Lightning Email Templates cannot match. The template uses messaging:emailTemplate as the root tag and renders dynamic content based on the recipient and the related record. For transactional emails (order confirmations, invoices, appointment reminders, customer notifications) where the email needs sophisticated formatting and dynamic content, Visualforce email templates are still the right tool.
Visualforce for PDF generation
Adding renderAs="pdf" to a Visualforce page tells the platform to render the page as a PDF document instead of HTML. The PDF is generated server-side using a PDF rendering engine and can be returned to the user as a download or attached to a record. This pattern is the standard way to generate Quote PDFs, Order confirmations, Invoice documents, Service Reports, and other customer-facing PDFs in Salesforce. LWC does not natively support PDF generation, so Visualforce remains the right tool for these scenarios. Custom Visualforce components for headers, footers, line item tables, and signature blocks make the PDFs maintainable and reusable.
Visualforce Sites and public pages
Salesforce Sites uses Visualforce pages to host public-facing content that does not require authentication: lead capture forms, FAQ pages, public registration flows, lightweight customer-facing portals. Visualforce Sites is the older offering compared to Experience Cloud (which builds on LWC), but it remains useful for simple public scenarios where the full Experience Cloud overhead is not warranted. Sites Visualforce pages run as a guest user with restricted permissions, requiring careful design to avoid exposing sensitive data. The Sites configuration is part of the broader Sites and Domains setup area.
The migration path to LWC
Most orgs are gradually migrating Visualforce pages to Lightning Web Components. The migration is not automatic, but several patterns make it manageable. The hybrid approach: keep the Visualforce page and embed an LWC inside it via lightning-out, allowing piecemeal modernization. The wrapper approach: build an LWC equivalent and update the calling code to use the LWC instead of the Visualforce page, retiring the Visualforce page when no callers remain. The full rewrite: redesign the page in LWC from scratch using Lightning App Builder for layout. The right choice depends on how interactive the existing page is, how many callers reference it, and how much value the rewrite adds. Pages used for email templates and PDF rendering should stay in Visualforce because LWC does not yet replace either scenario.
Maintaining a Visualforce codebase in 2026
For orgs with substantial Visualforce footprints, the right operational posture is maintenance plus migration. Maintenance means keeping the existing Visualforce pages working as Salesforce releases evolve: addressing deprecation warnings, updating API versions when needed, fixing bugs as they surface, and watching for any platform changes that might affect rendering or behavior. Migration means systematically replacing Visualforce pages with Lightning Web Components on a defined cadence: prioritizing high-traffic pages, pages with the most user friction, and pages that would benefit most from modern interactivity. The migration cannot be rushed; rewriting every Visualforce page in a single project is rarely the right choice because the business value of a rewrite varies significantly per page. The pages that should never be migrated are email templates and PDF generation pages, where Visualforce remains the platform's supported path. For those scenarios, treat the Visualforce code as a long-term investment and invest accordingly in maintainability, test coverage, and clear documentation. The Visualforce framework will continue to be supported by Salesforce for the foreseeable future, but the rate of new feature investment is essentially zero. Treating it as a stable, mature framework that will not get new bells and whistles helps set the right expectations for the development team.
Build a Visualforce page
Creating a Visualforce page is straightforward but the design considerations matter for performance, maintainability, and the migration path to LWC. The walkthrough below covers the standard sequence for building a new Visualforce page in a Salesforce DX project.
- Decide whether Visualforce is the right choice
Before building a new Visualforce page, confirm Visualforce is the right tool for the use case. For email templates and PDF generation, yes. For new interactive UI scenarios, evaluate LWC first. Document the rationale in the code comments or a design document so future maintainers know why Visualforce was chosen rather than the modern alternative.
- Create the page with a standard or custom controller
From VS Code with the Salesforce Extensions, create a new Visualforce page file with the appropriate API version. Add the apex:page root tag with the controller (standardController for object-based pages, controller for custom Apex controllers, or extensions for the hybrid approach). Add the page content using standard tags. Save and deploy to a sandbox for testing.
- Implement controller logic and reusable components
Write the Apex controller class with the methods the page references: properties, action methods, page references. Cover the controller with unit tests at 75 percent or higher coverage. For UI patterns that recur on multiple pages, extract them into Visualforce Components so the markup stays DRY. Test the page in the sandbox with realistic data, including edge cases (empty data, large data sets, validation errors).
- Deploy and monitor
Promote the page and controller through the standard deployment pipeline. Add the page to the relevant page layouts, custom buttons, or app routing. Test in production with a small group of users before broader rollout. Monitor for performance (view state size, render time) and any errors in the debug logs during the first week. Update documentation in the team's wiki so future maintainers can find the page.
The unique identifier and human-readable label for the page.
The Salesforce API version the page targets, affecting available features and runtime behavior.
The Apex class providing data access and behavior for the page.
Required to create and edit Visualforce pages in the org.
Apex test classes meeting 75 percent coverage are required for production deployment.
- View state has a 170 KB limit. Pages with large datasets in instance variables hit this limit and produce confusing errors at render time.
- Visualforce pages in Lightning Experience run inside an iframe. Some styling and JavaScript behavior differs from the standalone Visualforce rendering.
- Standard Controllers work only with the object they are bound to. Cross-object work requires custom controllers or extensions.
- Apex unit test coverage applies to controllers, not to the Visualforce markup. The markup itself is not test-coverable in the standard way.
- Visualforce pages do not auto-refresh on field changes the way LWC does. Every interaction is a server round trip.
Trust & references
Cross-checked against the following references.
- Visualforce Developer GuideSalesforce Developer Docs
Straight from the source - Salesforce's reference material on Visualforce.
- VisualforceSalesforce Developer Docs
- Render Visualforce as PDFSalesforce Developer Docs
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 required before deploying Visualforce-related code to production?
Q2. What skill set is typically needed to work with Visualforce?
Q3. Where would a developer typically work with Visualforce?
Discussion
Loading discussion…