How to export all files and attachments from Salesforce

Exporting records from Salesforce is easy. Exporting the files is where people get stuck. Maybe you are leaving an org, moving to a new document system, handing a client everything attached to their account, or your file storage is full and you want to archive old files before deleting them. Whatever the reason, you need the actual files out, not just a list of their names.

This guide covers the four ways to do it, what each method really gets you, and the limits that tend to show up halfway through.

First, know what kind of files you have

Salesforce has stored files in three different ways over the years, and your org may have all three:

• Salesforce Files (ContentDocument and ContentVersion). The modern standard. One document can have many versions and can be shared with many records, users and libraries at once through ContentDocumentLink.
• Attachments (Attachment). The older model. Each attachment belongs to exactly one parent record.
• Documents (Document). Files kept in folders on the Documents tab, often logos and email template images.

The file content itself sits in a binary field (VersionData on ContentVersion, Body on Attachment and Document). That is why a normal report or CSV export shows file names and sizes but never the file.

Before you pick a method, check which of the three you actually use. Many orgs that moved to Lightning years ago still have thousands of legacy attachments on old records.

Option 1: Salesforce's Data Export service

This is the built-in backup in Setup → Data Export. It is free and needs no tools.

How to include files:

1. In Setup, search for Data Export and choose Export Now or Schedule Export.
2. Tick Include images, documents, and attachments (Attachments and Documents).
3. Tick Include Salesforce Files and Salesforce CRM Content document versions (Salesforce Files).
4. Select the data to include (or Include all data) and start the export.

Salesforce emails you when it is ready, and you download the ZIP files from the Data Export page.

The limits, from Salesforce's own help article:

• How often. Weekly exports are available in Enterprise, Performance and Unlimited editions. Other editions (except Database.com) get monthly exports. You can run one manually only every 7 days (weekly) or 29 days (monthly).
• No sandboxes. The export service is not supported in sandboxes. A request there never completes.
• 512 MB pieces. Large exports are split into multiple ZIP files of roughly 512 MB each. An org with 300 GB of files means hundreds of ZIPs.
• One download per minute. You can download the ZIP files one at a time with a 60-second wait between each.
• 48 hours to download. The ZIPs are deleted 48 hours after the email is sent, not counting weekends. If you have hundreds of files to download one per minute, plan the time.
• Only active users. If the person who scheduled the export is deactivated, the export stops running.

What you get: CSV files for every object, plus the binary files named by their Salesforce ID. To work out which file belonged to which record, you join ContentVersion to ContentDocumentLink (or Attachment.ParentId) yourself in a spreadsheet or a script. Fine for a disaster backup, painful when someone asks "give me every file attached to these 40 accounts".

Best for: a free, full-org safety copy on a regular schedule.

Option 2: The REST API (or a script)

Every file can be downloaded through the API. For Salesforce Files, query the versions you want and fetch each one's content:

SELECT Id, Title, FileExtension, ContentSize, ContentDocumentId
FROM ContentVersion
WHERE IsLatest = true

Then download each file from /services/data/vXX.X/sobjects/ContentVersion/{Id}/VersionData. For legacy attachments the equivalent is /sobjects/Attachment/{Id}/Body.

To find the files on specific records, query ContentDocumentLink. Salesforce requires you to filter it by LinkedEntityId or ContentDocumentId, so you usually query the records first, then their links, then the versions.

Things to plan for:

• API limits. Each download is an API call. Tens of thousands of files can use a large share of your daily allowance, so run big jobs out of hours.
• Visibility. The API returns only the files the running user can see. An admin without access to private files, or files in libraries they are not a member of, will silently miss some.
• Large files and retries. Multi-gigabyte files and dropped connections need a script that can resume, check sizes and record what failed.
• Duplicate names. Two files called Contract.pdf will overwrite each other unless you name files by ID or put them in per-record folders.

Best for: developers who need a repeatable, custom export and are happy to own the script.

Option 3: Data Loader

Data Loader is the tool most admins reach for first, because it is already installed. It is very good at exporting the records: ContentVersion, ContentDocumentLink and Attachment rows with their IDs, titles, sizes and parent IDs.

It is not built to turn a large set of file bodies into a folder of usable files. Treat its export as the index of your files: a list that tells you what exists, how big it is and what it is linked to. Then get the files themselves another way.

Best for: listing what you have and sizing the job before you pick a method.

Option 4: A dedicated file backup tool

If you need the files and the context (which record, which owner, which library) without writing joins yourself, a purpose-built tool does the plumbing: it scans, downloads with retries, and writes a manifest next to the files.

This is what File Backup in orgadmin.ai does for Salesforce Files:

• Scan first, export second. A background scan inventories every file the connected user can see and records what each is attached to: record, user, group, library or the org itself. The scan tells you honestly whether it saw the whole org or only what that user can access, so you know if anything was missed.
• Find the big ones. Browse and filter by object, record, owner, type and size, so you can see what is actually filling your file storage before you decide what to keep.
• Aim it with SOQL. Instead of the whole org, pick an object and write your own WHERE clause, such as cases closed more than three years ago, and the scan takes only the files attached to those records. You can also choose record fields to capture alongside them.
• A ZIP with a manifest. The export is a ZIP with the files plus manifest/files.csv, links.csv (what each file is attached to), errors.csv (anything that failed, so nothing goes missing quietly), records.csv for SOQL-scoped exports, and a README. Multi-gigabyte files are handled, and jobs can be cancelled.
• Then reclaim storage, separately. Once you have checked the archive, bulk-delete only the files that export actually captured, and only into the Recycle Bin. This step is off unless an operator turns it on, and it is a separate action from the export.

One honest limit: File Backup covers Salesforce Files (ContentDocument). It does not export legacy Attachment or Document records, so use Data Export or the API for those.

Best for: archiving or clearing files on a set of records, a decommission or migration, or answering "what is using our storage?"

Which method should you use?

Before you delete anything

If the goal is to free up storage, do it in this order:

1. Export the files you plan to remove.
2. Check the archive. Open it, compare the file count and total size with what you expected, and read the error list.
3. Store it somewhere you control, with a note of the date, the org and the filter you used.
4. Delete, ideally into the Recycle Bin first, so you have a short window to undo a mistake.
5. Watch file storage in Setup → Storage Usage to confirm the space came back.

For a wider move between orgs or systems, our Salesforce data migration checklist covers the records side.

Checklist

• Find out whether you have Salesforce Files, Attachments, Documents, or all three
• Size the job with a ContentVersion or Attachment export first
• Use Data Export (both file boxes ticked) for a regular full-org backup
• Plan for 512 MB ZIPs, one download per minute and the 48-hour window
• Use the API or a tool for sandboxes and for files on specific records
• Keep a manifest that links each file to its record
• Check the archive before deleting anything

Last checked 22 October 2026 against Salesforce Help, Export Backup Data from Salesforce. Export limits can change between releases, so check the current article before you plan a large job.