Since Winter '27, Salesforce shows the Web Console by default and hides the Developer Console. If you have used the Developer Console for years, you will want to know two things before you switch: what the Web Console does better, and what you give up.
We went through Salesforce's Web Console guide and the Developer Console help pages and compared them task by task. Where Salesforce's own documents disagree, we say so. (If the Developer Console has simply disappeared and you want it back, start with Developer Console not visible in Salesforce?. It takes an admin about a minute.)
The short version
- The Web Console is the newer, broader tool. It is built on VS Code for Web, handles all metadata types including Lightning Web Components, and keeps project context between files.
- The Developer Console still has the deeper debugging tools. It has the Log Inspector with custom perspectives, checkpoints and heap inspection, a View State tab, and a test runner with code coverage and test suites.
- Neither has AI, git or a terminal. Salesforce positions both as tools for quick, in-org work, not for building features.
- You can run both. If both are set to Active in Setup, both appear in the gear menu.
Side by side
| Developer Console | Web Console | |
|---|---|---|
| Built on | Salesforce's own editor | VS Code for Web |
| Metadata types | Apex, Aura and Visualforce | All metadata types |
| Lightning Web Components | Not supported | Supported, with language support |
| Project context | None. Files open one at a time | Kept, with in-context editing |
| SOQL and SOSL | Query editor, results grid, query plans | SOQL execution and a Query Plan Inspector |
| Anonymous Apex | Yes | Yes |
| Debug logs | Log Inspector, custom perspectives, open source from a log | Docs disagree (see below) |
| Checkpoints and heap | Yes | Not documented |
| Tests and code coverage | Tests tab, test runs, test suites, coverage | Not documented as a separate runner |
| Extensions | None | Prepackaged only. No Marketplace installs |
| Terminal or CLI | No | No |
| Apex in production | Not editable (Salesforce has never allowed direct Apex edits in production) | Read only, and the Edit links are hidden |
| AI | None | None |
| Government Cloud | Available (see the Winter '27 known issue) | Not available yet |
Sources: Salesforce's Developer Console vs Web Console page, the Web Console FAQ, and the Developer Console section of Salesforce Help. "Not documented" means we could not find it in the Web Console guide. It does not mean the feature is definitely missing, so check in a sandbox.
Task by task
Writing and editing code
This is where the Web Console is clearly better. The Developer Console supports only Apex, Aura and Visualforce, and opens each file on its own. The Web Console supports every metadata type, gives Lightning Web Components proper language support, and keeps a DX-style project in its Explorer. You can open several editors side by side and search and replace across the project.
When you save, Salesforce says the file deploys straight to the org that opened the Web Console. There is no local copy and no commit. Each org's files are kept separate by its My Domain, so you cannot open one org's project from another org.
Running queries
Both consoles run SOQL. The Developer Console has a query editor, a results grid, SOSL searches and a query plan tool. The Web Console FAQ lists SOQL execution and a Query Plan Inspector. For everyday queries, there is little to choose between them.
Reading debug logs
This is where to be careful, because Salesforce's own pages disagree:
- The comparison page says the Developer Console has the richer log views, including several views and the ability to open source code from a log. It says the Web Console shows logs as raw text unless you add tools or extensions.
- The FAQ says the Web Console closes Developer Console gaps with a Debug Logs Viewer.
The Web Console is changing quickly, so the FAQ is probably the more recent of the two. But the comparison page's point about extensions still matters: you cannot install anything from the Marketplace yourself. If you rely on the Developer Console's Log Inspector, especially custom perspectives, open a real log from your org in the Web Console before you switch the Developer Console off.
Testing and debugging
The Developer Console's Tests tab lets you create test runs, manage test suites and check code coverage line by line. Its checkpoints let you capture the heap at a point in your Apex, and the Checkpoint Inspector shows the variables in it. The View State tab shows a Visualforce page's view state.
The Web Console's interface includes a Run and Debug view, and the FAQ talks about "testing and validation workflows" in non-production orgs. We could not find a documented equivalent of test suites, line-by-line coverage or checkpoints. If your team uses them, keep the Developer Console active for now.
Anonymous Apex
Both have it. The Web Console FAQ lists Anonymous Apex among the gaps it closes. That matters, because anonymous Apex was one of the main reasons people kept the Developer Console open.
Production orgs
Salesforce describes the Web Console as preserving "production guardrails": in production, Apex is read only, and the Edit links on the Apex Classes, Triggers and Jobs pages are hidden. That is not new. Salesforce has never let you edit Apex directly in a production org, from the Developer Console or anywhere else. Apex reaches production through a deployment.
Access and setup
The permissions are different, and this catches people out after the upgrade:
| Developer Console | Web Console | |
|---|---|---|
| Permissions to open it | API Enabled and View All Data | Web Console User and View All Data. Add Use Any API Client if API access control is on |
| Who switches it on | An admin, under Setup → Web Console → Enable Developer Console | An admin, under Setup → Web Console → Enable Web Console |
| Editions | Enterprise, Performance, Unlimited, Developer, Database.com | Developer, Professional, Enterprise, Unlimited, Performance and Partner editions. Professional orgs get restricted access |
| Where to open it | Gear menu (Lightning) or your name (Classic) | Gear menu, or the Edit links on the Apex Classes, Triggers and Jobs pages |
Two settings decide what your users see:
- Web Console Active, Developer Console Inactive: only the Web Console appears, and Edit links open there.
- Web Console Inactive: the Developer Console turns back on by default and Edit links open the old Apex editor.
- Both Active: both appear in the gear menu. Edit links open the Web Console.
After changing either setting, refresh the page or wait a few seconds for the gear menu to update.
So which should you use?
- Lightning Web Components, or edits that span several files: the Web Console. The Developer Console cannot help.
- Quick SOQL, anonymous Apex, or a small sandbox fix: either. The Web Console is where Salesforce is investing.
- Test suites, line-by-line coverage, checkpoints or the Log Inspector's perspectives: keep the Developer Console active alongside the Web Console.
- Feature work with git and scratch orgs: neither. Salesforce points you to the Agentforce Vibes IDE, which it describes as a paid tool, or VS Code with the Salesforce CLI.
Our advice for most teams: turn both on for a release or two, let people use whichever fits the task, and collect the list of things that still send them back to the Developer Console. Salesforce asks for exactly that feedback in its Web Console feedback repository.
What neither console does
Both consoles assume you do the work: you open the class, read the log, write the query and find the broken line. Neither has AI, and neither can move a change from one org to another.
That is the gap the orgadmin.ai Development Studio fills. It is a browser studio connected to your orgs, with an AI agent that does the investigating:
- It reads your org before it writes anything: your objects and fields, existing Apex and triggers, flows and other automation, and live data through SELECT-only queries.
- It edits your project in place, changing the exact lines that need to change rather than pasting a whole new file.
- It reads the real errors. After you validate or deploy, it pulls Salesforce's compile errors and test failures, with line numbers and assertion messages, and fixes what they point at.
- It moves changes between orgs. Projects deploy as one package. Against production the default is a check-only validation, and you can then quick-deploy the validation that passed.
- It analyses logs, not just displays them. Debug Logs looks across up to five related logs for exceptions, slow SOQL and DML, and limit use.
- It writes SOQL from plain English in the SOQL console.
- It works with your own AI agent too. The MCP server gives Claude Code, Codex, Cursor or Claude Desktop the same org tools, under the same permissions and audit log.
The guardrails are deliberate. The AI never starts a deployment by itself: a person presses Deploy or Validate. Production needs a confirmation every time. Write access is off until you turn it on.
It is not a replacement for everything a console does. It has no anonymous Apex, no checkpoints, no standalone test runner (tests run as part of a validation or deployment), and no git or CLI. Many teams will keep the Web Console for a quick look inside the org and use the Studio for changes they want reviewed, tested and promoted.
Try it on a sandbox. Start a free orgadmin.ai trial, connect a sandbox (the first 15 minutes guide shows how), and give the Studio the last Apex bug you fixed by hand in the Developer Console.
Sources
- Developer Console vs Web Console, Web Console FAQ, Enable Web Console, Launch Web Console, Web Console user interface, Supported org types and Web Console vs Agentforce Vibes IDE (Salesforce Developers)
- Web Console (Salesforce Winter '27 Release Notes)
- Open the Developer Console and the Developer Console section of Salesforce Help