The Salesforce Developer Console cannot export query results to a file. There is no export button and no right-click download in the Query Editor: you can select and copy what is on screen, but producing a real CSV requires a different tool. For small result sets, copy the grid into a spreadsheet. For anything larger or repeatable, use Data Loader, SOQL Builder, or the Salesforce CLI.
This guide covers how to run a SOQL query in the Developer Console, then five ways to get those results into a file, with the limits and permissions for each.
Can You Export Query Results Directly from Salesforce Developer Console?
No. This is the single most common misunderstanding about the tool, so it is worth being precise about what is and is not possible.
What you can do is select rows in the results grid and copy them to your clipboard, then paste into Excel or Google Sheets. That is a manual copy, not an export. It has no file format, no encoding control, and no way to schedule or repeat it.
What you cannot do is generate a CSV from the Console itself. The Query Editor is a development and debugging tool, not a data extraction tool. Its results grid is also capped, commonly reported at around 2,000 rows, so even the copy approach breaks down on larger datasets. If you need a file, you need one of the methods below.
What Is the Salesforce Developer Console Query Editor?
The Developer Console is a browser-based development environment for editing Apex, viewing debug logs, and inspecting data. The Query Editor is the panel at the bottom where you write and execute SOQL against your org and see results in a grid.
When to use it: the Query Editor is the fastest way to check whether a query returns what you expect, validate a filter before putting it into Apex, or spot-check a handful of records after a data change. It is built for inspection, and it is excellent at that. It is not built for extraction, which is why the rest of this guide exists.
How to Run a SOQL Query in Salesforce Developer Console
Open the Developer Console and Query Editor
- Click the gear icon in the upper right of Salesforce, then select Developer Console. It opens in a new browser window.
- At the bottom of the window, select the Query Editor tab.
Enter and Execute Your SOQL Query
- Type or paste your SOQL into the Query Editor field. A simple example to start with:
4. Click Execute. Results appear in the grid below, with one column per field you selected.
If the query errors, check that every field name is spelled correctly and exists on the object, and that you have read access to each one. Results reflect what your user can see, not everything in the org.
How to Export Query Results from Salesforce Developer Console
Five methods, ordered from simplest to most robust. All except the last are officially supported by Salesforce.
Method 1: Copy Small Query Results into Excel
Best for a handful of rows you need right now.
5. Run your query in the Query Editor.
6. Click the first cell in the results grid, then shift-click the last cell to select the range.
7. Press Ctrl+C (Cmd+C on Mac).
8. Paste into Excel or Google Sheets, then save as .csv if you need a file.
Column headers may not come across cleanly, and formatting is unreliable for long text or fields containing commas. Treat this as a quick lift, not a repeatable process.
Method 2: Export the SOQL Results with Data Loader
Best for large exports and anything you need as a proper CSV. Data Loader is a supported Salesforce client application and handles far more rows than the Console displays.
9. Open Data Loader and click Export. (Use Export All if you also need records in the Recycle Bin.)
10. Log in and select your org environment.
11. .Choose the object you are querying, then pick a destination and filename for the CSV.
12. Select the fields you want, or switch to the SOQL editor and paste your query directly.
13. Click Finish to run the extraction, then open the CSV to confirm the row count matches what you expected.
Data Loader uses the API, so the running user needs the API Enabled permission plus read access to the object and every field in the query.
Method 3: Save Results with SOQL Builder
Best if you already work in VS Code. SOQL Builder ships with the Salesforce Extension Pack and is the closest thing to a genuine one-click export among the supported tools.
14. Install the Salesforce Extension Pack in VS Code and authorise your org.
15. Create or open a file with a .soql extension, then open it in SOQL Builder.
16. Build your query visually, or paste existing SOQL into the text editor and toggle between the two views.
17. Run the query to see results in the panel below.
18. Click one of the Save icons on the results panel to save the output as a .csv or .json file.
Add your saved output paths to .gitignore so exported data does not end up committed to source control or deployed to an org.
Method 4: Export with Salesforce CLI
Best for recurring or scripted exports. Because it runs from the command line, it can be scheduled or dropped into a pipeline.
19. Install Salesforce CLI and authorise your org.
20. Run your query with a CSV result format and redirect the output to a file, for example:
21. Open the resulting file to verify the rows and headers.
One limitation worth knowing: Salesforce notes that the CLI does not currently support bulk queries, so very large result sets are better handled by Data Loader.
Legacy Option: Export with Workbench
Use with caution. Workbench can run a SOQL query and download results as CSV, and many admins still reach for it out of habit. It is no longer a sensible default. Salesforce publishes replacement guidance for Workbench stating that Salesforce does not maintain the tool, cannot address bugs in it, and cannot guarantee it will remain available, recommending Code Builder, Salesforce CLI and the VS Code extensions instead. Workbench’s own documentation states that it is not a supported Salesforce product and advises against using it with production data. If you use it, treat it as a temporary convenience and move recurring work to a supported tool.
Which Export Method Should You Use?
Match the method to the size of the result set and whether you will need to run it again.
Common Export Problems and Solutions
Empty results. Usually a filter problem or a visibility problem. Remove the WHERE clause and re-run: if rows appear, the filter is wrong. If nothing appears, your user probably lacks read access to the object, or the records are owned by others and your sharing model restricts them.
Fewer rows than expected. A SOQL query returns only what the running user can see, so a query run by an admin and the same query run by a standard user can legitimately return different counts. The Developer Console grid also caps how many rows it displays, so check the actual file rather than the on-screen grid.
Permission errors. Data Loader and the CLI both require the API Enabled permission on the user profile or a permission set, plus field-level read access to every field in the SELECT clause. A field the user cannot see will fail the query rather than silently omit the column.
Broken characters or misaligned columns in the CSV. This is an encoding issue. Export as UTF-8, and when opening in Excel use the import flow and specify UTF-8 rather than double-clicking the file, which is what mangles accented characters. Text containing commas or line breaks needs proper quoting, which is another reason to prefer a real export over a clipboard copy.
Relationship queries look wrong. Parent fields use dot notation, such as Contact.Account.Name. Child subqueries return nested results that do not flatten neatly into a single CSV row, so exporting parent and child records separately and joining them afterwards is usually cleaner.
Export Salesforce Query Results Reliably
The Developer Console is for inspecting data, not extracting it. Run and validate your SOQL there, then pick the export path that matches the job: clipboard for a quick look, SOQL Builder if you live in VS Code, Data Loader for volume, and the CLI for anything you will run more than once.
One caveat worth stating plainly: an exported CSV is a snapshot, not a backup. It captures the fields you selected at the moment you ran the query, without relationships, metadata, attachments, or any way to restore records to the org. It is fine for analysis and for handing data to another system. If the goal is protecting your org against data loss, that calls for real backups with point-in-time recovery, rather than a folder of spreadsheets.
Frequently Asked Questions (FAQ)
Thank you for subscribing



