The Developer Console is Salesforce’s built-in, browser-based IDE for Apex, SOQL, and platform debugging. It opens straight from the gear menu (Setup → Developer Console) in any org — sandbox, scratch, or production — without installing anything.
Despite being the official tool, Developer Console is no longer the default editor for most Salesforce work — VS Code with the Salesforce Extensions Pack and the Salesforce CLI has taken that spot. But Developer Console remains the fastest path for: quick anonymous Apex, ad-hoc SOQL, reading debug logs in a sandbox, and lightweight code-fix triage in production where VS Code isn’t connected.
What you can do in it
- Write and save Apex classes, triggers, Visualforce pages, and Lightning Components (Aura — LWC is read-only here).
- Execute Anonymous Apex — paste a snippet, run it, see the results.
- Run SOQL/SOSL via the Query Editor with toggle for tooling-API objects.
- View debug logs with a syntax-highlighted, filterable viewer.
- Use the Log Inspector — drill into one log to see the execution tree, stack, source, variable state, and limits used.
- Run Apex tests and view code coverage line-by-line.
- Open metadata in the org (custom objects, fields, page layouts) for quick inspection.
The Log Inspector
The single most useful feature for Apex debugging. Open a log → toggle perspectives:
- Execution Log — the raw log file.
- Source — the Apex code with hit-count markers and execution-time indicators.
- Variables — values at each scope.
- Stack Tree — visual call hierarchy.
- Execution Stack — left-to-right list of every method invocation.
- Limits — running totals of SOQL, DML, CPU, heap.
For a “why is my trigger using too much CPU?” investigation, Source + Limits in the Log Inspector is usually faster than VS Code’s log viewer.
Strengths
- Zero setup — works in any browser, in any org.
- Excellent anonymous Apex experience: run, see output, no commits.
- The Log Inspector is genuinely good and not replicated in VS Code.
- Tests run with coverage you can see on each line.
Weaknesses
- No source control integration — every save commits straight to the org.
- No multi-file editing across an SFDX project.
- LWC code is read-only.
- No diff view or rebase support.
- Performance degrades on classes over a few thousand lines.
When developers reach for it in 2026
| Task | Best tool |
|---|---|
| Writing new LWCs and Apex with version control | VS Code + Salesforce CLI |
| Quick anonymous Apex in a sandbox | Developer Console |
| Inspecting a production debug log | Developer Console |
| Bulk metadata operations | SFDX / sf CLI |
| Running an Apex test with coverage gutters | Either — DC for one-class quick checks, VS Code for project-wide runs |
What interviewers are really looking for
Naming “browser IDE for Apex and SOQL” is the floor. Strong signals: you mention the Log Inspector for debug-log analysis, you note that anonymous Apex is the killer feature, and you acknowledge that VS Code + Salesforce CLI is the modern primary tool while Developer Console remains valuable for in-org triage and log inspection. A staff-level answer notes that Developer Console writes directly to the org — useful in a pinch, dangerous without source control.
Verified against: Salesforce Help — Developer Console. Last reviewed 2026-05-17.