How to export your data from Discord

How to export your data from Discord starts with knowing what the Data Package holds

A server owner or IT lead who needs a community's history out of Discord before a renewal, a policy change or a move should first understand the limit of Discord's self-service tool. The per-user Data Package returns one member's own activity and attachment links, and it does not return a server's full message history. This section explains what can and cannot be exported. The rest of the page covers formats, limits, the export sequence and contract planning.

For each account, the package contains the messages that account sent, the servers it belongs to and its activity records, all as JSON. Attachments are listed as links to Discord's content delivery network, so the files depend on those links still working when you download them. Messages written by other members, the full content of channels the account did not post in, and the history of a channel as a whole are not included in any individual's package. Confirm with Discord what the package contains for your account type, because the file structure is something you should check against your own export.

Treat the package as a record of one person's participation. Before you ask members to request theirs, decide what the community actually needs: channel history, a membership list or a record of decisions. Each need points to a different path, and most cannot be met by a per-user download alone. Write down the retention period you require and the date your renewal or move takes effect, then check how long Discord takes to deliver a package for your account before you set any deadline.

Which Discord data types the Data Package and other paths can export

This table compares which Discord data types a personal Data Package can carry and where each one stops. Treat the format and limit cells as the baseline for your own account, and check every cell marked to confirm in the Discord help center before you plan an export. The main takeaway is that a personal request covers your own material, not a server's full message history.

Data type	Export path	Format	Limits and what to confirm
Your sent messages	Data Package requested from your account settings	JSON	Confirm the current file layout and any size limit in the Discord help center
Servers you belong to	Data Package	JSON	Lists your server memberships, not each server's channel history; confirm the fields included
Your activity records	Data Package	JSON	Confirm which activity events are included and how far back they reach
Attachments and images you posted	Linked from the Data Package as CDN links	Links to files, not bundled files	Confirm how long the links stay valid before downloading
Other members' messages in a server	Not included in a personal Data Package	Not applicable	Confirm with Discord which exports, if any, cover messages from other members
Full channel history for a community	Not available to server owners through the personal Data Package	Not applicable	Confirm any official server-level export option in the Discord help center before planning
Voice and video content	Not included in the personal Data Package	Not applicable	Confirm current Discord policy for voice and video retention and export

What Discord's Data Package cannot give a server owner

Discord's Data Package is built around each user's own activity, so it cannot serve as a community archive. The gaps below share one cause: a server owner holds no export that covers everyone's messages, private spaces and attachments. Plan the workaround before the server goes quiet, not after.

Other members' messages

A personal Data Package holds the messages that the requesting account sent, not the messages posted by everyone else in a server. A server owner who requests only their own package will hold a partial record of the community. The workaround is to ask each active member to request their own package and share the messages they want kept, which is slow and incomplete. Check how many members will respond before you promise a complete archive to anyone.

Full channel history

Channel history is not a per-user export, so the package cannot reconstruct what a channel said over its lifetime. Messages from members who have left, or from periods before an account was active, are typically absent. The workaround is to capture history while the server is still active, either with a bot your team operates or with a bridge such as mautrix-discord that relays new messages to the destination. Confirm with the bridge documentation which history it can backfill before you rely on it.

Private and moderator-only content

Private channels, role-restricted areas and moderator-only discussions are visible only to the people who hold access to them, so a member's package will not include content they could not see. Moderation logs and staff notes are similarly outside a member's own data. Identify these spaces early, list the roles that can read them, and decide whether those moderators should export their own material before they lose access.

Attachments held as CDN links

Files and images in a personal package appear as links to Discord's content delivery network rather than as copies stored with the data. Links can expire or break when a message or server is removed, so the file may disappear even though the record remains. The workaround is to download the attachments you need from a channel while the server is active, store them with their message metadata, and verify a sample of links after the export.

Accepting and documenting the gap

Some history will be lost, and a clear written record of what was and was not captured protects the owner later. Document the export date, the members who contributed, the channels covered, the packages collected and the attachments that failed. Share that scope with members so no one assumes a complete archive exists. This record also helps auditors and legal teams understand what the organization can and cannot produce.

Why a server owner cannot export a community's full history this way

The Data Package is generated for the one user who requests it, so it contains that user's own data: the messages that user sent, the servers they belong to and their activity records, with attachments referenced as CDN links. It cannot assemble the messages written by everyone else in a channel. A server owner who asks for a package therefore receives only the owner's own history, not the conversation the community actually had. Owning the server does not change this, because ownership grants administrative control inside Discord, not a per-user export of other members' content.

The consequence matters most for three situations: a retention policy that requires keeping community conversations, a legal hold that requires preserving them, and a migration that needs the history to move with the community. In each case the archive has to cover every member's messages in each channel, and a per-user package cannot provide that. Before planning around any export route, confirm with Discord what its current export options cover for server-level content, and ask your legal and records teams which parts of the community history they must keep.

Plan for the gap now rather than at the moment of a request. Decide which channels carry records you must keep, start capturing them in a system you control from the point the decision is made, and document what was lost before that point. Whether any older history can be recovered by other means depends on Discord's own retention behavior, which you should verify directly rather than assume. Bridging or dual running can capture new messages while the community moves, but it does not reconstruct the past.

The export sequence for a complete archive, with verification at each step

This sequence turns a Discord community into a verified, checksummed archive that you can convert and reuse, and it shows where each piece of evidence comes from. It separates what each member can export on their own from what only a live capture of channel history can reach.

Inventory every server, channel and thread
The server owner or an administrator lists each server you need to preserve, then records every text channel, forum channel, thread and voice channel with its ID, purpose and retention notes. Include who holds the owner and admin roles, since they control the capture work. The output is a single inventory sheet with one row per channel. You know this step is done when every channel you care about has a row and a named person responsible for it.
Collect each member's Data Package
Each relevant member requests their own Data Package from Discord's account settings and receives a set of files covering their sent messages, servers and activity as JSON, with attachments referenced as CDN links. Ask members to request it themselves, since the package is per user and an owner cannot request it for them. The output is one archive per member, stored under a label that matches the inventory. You know this step is done when you have a package from every member you identified and a list of anyone who has not responded.
Choose a capture method for channel history
Because a server owner cannot obtain a community's full message history from Data Packages, decide while the server still runs how channel history will be captured. Options include a bot with the right read permissions, a bridge that mirrors channels into your target platform, or a documented manual export from a moderator's account. Confirm the method against Discord's current terms and your own policies before you start. The output is a written capture plan naming the method, the channels it covers and the person who runs it. You know this step is done when every inventory row is assigned to a method or marked as out of scope.
Run the capture and store raw files with checksums
Run the chosen capture method and save its output exactly as received, without editing, renaming or converting. Record a SHA-256 checksum for every file and keep a manifest that lists file name, source channel, capture date and checksum. Store the raw set in write-protected storage on infrastructure you control, with a second copy in a separate location. The output is the raw archive plus a manifest. You know this step is done when a checksum verification run over the stored set reports no mismatches.
Convert the raw files to the target format
Convert a working copy of the raw files into the format your target platform imports, such as the Slack-export or Mattermost bulk formats documented by the import tools you plan to use. Keep the raw archive untouched so the conversion can be repeated or corrected. Log every transformation, including how user IDs were mapped to accounts and how attachment links were handled. The output is a converted dataset and a conversion log. You know this step is done when the log accounts for every channel in the inventory and every skipped or remapped item has a stated reason.
Verify counts and attachments against a sample
Compare message counts per channel between the raw capture and the converted dataset, then pick a sample of channels and dates and open the source and target messages side by side. Confirm that attachments resolve, that threads keep their parent messages and that edited or deleted messages are handled as your policy says. Record any gaps as exceptions with a named owner. The output is a verification report with counts, sample results and an exception list. You know this step is done when every mismatch is either fixed or documented with an agreed disposition.
Confirm the archive is complete before shutdown
Before anyone leaves or any server is retired, review the inventory against the verification report and the member packages, and get sign-off from the owner of the archive. Store the final manifest, checksums and reports with the raw set so the archive can be audited later. Ask your counsel or compliance lead which retention and deletion rules apply to personal data in the packages. The output is a signed-off archive record. You know this step is done when every inventory row has a verified status and the record is stored with the archive.

How to verify an export before you delete anything

Do not delete anything on Discord, and do not let a contract lapse, until the export has been verified by a restore or import test. The Data Package is a per-user archive, so the check has to be run against what your community actually needs: the channel history, the attachments and the member context that a server owner depends on. Start by picking a handful of channels with different activity levels, then compare message counts per channel in the exported JSON with a count taken from the Discord client for the same date range. Discrepancies are expected where the archive covers only your own messages, so record them as known gaps rather than assuming the export is complete. Keep a short written log of each channel, its count and the person who checked it.

Next, test the files themselves. Open a sample of attachment links and confirm they resolve and that the files download in full, since CDN links can expire or point to content that was removed. Save the files into your own storage and check that names, sizes and file types match what was referenced in the JSON. Then confirm that the fields you need, such as message ID, author, timestamp, channel, reply references and edit history, map cleanly to the target schema of your chosen platform. Field names in the Data Package differ from those used by Matrix, Zulip or Mattermost importers, so write a mapping table and run a small sample through a staging instance. Confirm the exact field list and any version differences with Discord before relying on them.

Treat the restore or import test as the gate. Load the sample into a staging server, check that channels, threads, messages and attachments appear with correct order and authorship, and have a few members confirm the content looks right. Only after that passes should you plan deletion of Discord content or termination of any related subscription, and keep the verified export in encrypted, access-controlled storage with a retention date set by your records policy. Ask your legal and compliance owners to sign off on what the archive omits, because a clean technical test does not prove that the full community history was preserved.

Where the exported data can go: Matrix, Zulip or Mattermost

Synapse is the most widely documented Matrix homeserver. It is developed by Element and distributed under AGPL-3.0, with commercial licenses also available from Element, so your legal review will need to cover the AGPL terms if you modify and offer the server to users. Matrix is a federated protocol, which suits communities that want to control who they connect with, but it does not import a Discord export directly. Your team will have to decide how exported content is represented in rooms.

License: AGPL-3.0 applies to the Synapse distribution, and Element sells commercial licenses for organizations that cannot meet its terms.
Database: Synapse recommends PostgreSQL for production, with SQLite also supported for smaller setups.
Server name: The server_name setting fixes how user IDs and room identifiers are formed, so choose it before your first user signs in.
Federation: The federation_domain_whitelist setting can restrict federation to listed domains, and an empty list disables it.
Free edition: Element Server Suite offers a free AGPL Community edition that includes Synapse.

Before you choose Matrix, confirm with Element and your own platform team how exported messages will be loaded into rooms and which identity provider will sign users in.

What to plan before the Discord contract or server ends

Exporting a Discord community is a project with several parallel tracks, not a single download. The cards below cover the decisions and checks that run alongside the export, from timing and member notice to retention duties and moderator handover.

Confirm the export window

Before any server is archived or a subscription lapses, confirm with Discord what data remains available to you and for how long. Your per-user Data Package covers only your own activity, so the window to capture channel history is set by your own timing, not by a Discord export tool. Start the capture of community content while the server is still fully active.

Plan member communication

Members will not know whether their messages come with the community or stay behind. Tell them early what is moving, where, and what they need to do to request their own Data Package. Publish the new location in a pinned channel and keep the old server read-only for a set period so people can copy anything they need.

Map retention and legal hold duties

If your organization must preserve conversations for legal, regulatory or internal policy reasons, identify those obligations before deleting anything. Ask your legal and compliance teams which channels and time periods are covered, and record the decision. A Data Package from one user does not satisfy a hold on a whole channel.

Decide the destination platform

Choose the target before exporting, because the format you capture should match the import path you plan to use. Compare Matrix with Element, Zulip, Mattermost and Rocket.Chat against your needs for voice, roles, retention and federation. Confirm which features you require, such as SSO or compliance export, and whether they need a paid edition.

Run a restore test

Before you retire the Discord server, load a sample of exported content into the destination and check it. Confirm that messages keep their order, timestamps, authors and attachments, and that links to files still resolve. Note anything that does not transfer, since that becomes a known gap to communicate to members.

Hand over moderation roles

Discord roles, permissions and moderation logs do not carry over as a set. List every moderator and admin, their permissions and their responsibilities, then assign equivalent roles on the new platform before members arrive. Keep at least two accountable administrators on the destination so no single person holds the keys, and document who handles reports and bans.

Questions buyers ask before they export their Discord data

How much effort does exporting a Discord community really take?

The effort scales with what you need to move, not with a fixed price. Discord's per-user Data Package covers only the requester's own activity, so a community export means collecting each member's package or working with a bridge or migration tool. The main drivers are the number of servers and channels, the volume of attachments that must be downloaded from CDN links, and how many members actually participate. A small server with a few active channels is a bounded task. A large community with years of history, many attachments and inactive members is a much larger one. Ask any provider to break the estimate down by servers, channels, attachment storage and member count, and to state which data it will and will not cover.

How long does a Discord data export take?

Confirm the timing with Discord and with your own environment before you plan a cutover, because the duration depends on factors that are not fixed. Discord's Data Package is requested per user and its delivery time is set by Discord, so you should check the current turnaround in the Discord help documentation. Downloading attachments, converting files into a target format and reviewing the output each add time. Plan for a test run on one channel first, measure how long it takes at that scale, and extrapolate only after you know the attachment volume and the number of members who will respond.

What access and cooperation does the team need from Discord members?

A server owner or administrator can manage the server, but cannot pull the full message history of other members through their own account. Each member who wants their activity included must request their own Data Package, so you need their cooperation and a clear message explaining what to request and by when. Plan for the storage needed to hold downloaded attachments, which can be large, and for a person who can run conversions and check the results. Confirm with your legal and privacy team how member data may be stored and retained before collecting it.

Can our own staff run the export without outside help?

Yes, a technical team can do a small export in house, provided it has time, the skills to parse JSON and handle files, and a clear understanding of what is missing. The in-house work includes requesting and collecting packages, downloading attachments, mapping users and channels, running any import into the target platform and verifying the result. The risks are incomplete coverage, broken links to attachments, and loss of thread or reply context. Keep a written record of what was exported, what was excluded and why, so the community knows what history stays in Discord.

Does the export keep all messages, attachments and roles?

Not automatically. A per-user Data Package contains that user's own sent messages, server and activity records, with attachments referenced as CDN links, so it does not reconstruct the full channel history or permissions. Attachments may need to be downloaded before links expire or content is removed, and roles, permissions and moderation history generally need to be rebuilt manually in the target system. Ask any migration provider which of these items it will carry over and which it will leave for you to recreate.

When is outside help worth scoping for a Discord export?

Outside help is worth scoping when the community is large, the history must be complete, members are spread across many servers, or the data falls under retention or residency rules that your team must evidence. A fixed-scope engagement starts with a written definition of which servers, channels, date ranges and attachments are in scope, what deliverables are produced, and how the output is verified. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Request a written scope and quote that states exactly what is excluded.

What should we confirm with Discord before starting?

Confirm the current contents and delivery process of the Data Package directly with Discord, because the file layout and request steps can change. Also confirm how long attachment links remain valid, what Discord's terms say about exporting member content, and whether your server's settings affect what members can request. Record these answers with dates in your project file, since they determine what the export can and cannot deliver before any conversion work begins.

How DeployOpen works on this

DeployOpen approaches a Discord data exit as a fixed-scope piece of work inside your own infrastructure. We first agree in writing which Discord data you need to keep, where it will be stored, and who will be able to search it, then build and document the handover.

How we scope

Inventory which servers, channels and users are in the export, and which parts of the community history you actually need to keep.
Confirm which Discord data sources you hold, such as personal Data Packages and any server content you can legitimately access, and what each one contains.
Agree in writing the target platform, storage location, access model and retention rules before any extraction work starts.

How we build

Set up the self-hosted target in your cloud account, data center or air-gapped network, using the platform chosen in the written scope.
Convert exported JSON and attachment links into a format the target can import, and test the import on a copy before running it for real.
Check imported messages, attachments and user mappings against the source data, and record any gaps the export format cannot close.

How we hand over

Deliver the configuration, import scripts, runbooks and a record of what was and was not migrated, so your team can repeat or audit the steps.
Document the limits of the Discord export in plain terms, including what cannot be recovered from per-user data.
Walk your administrators through access control, backup and retention settings on the new system before the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is complete.
Ask for the support boundaries, response expectations and upgrade responsibilities to be written into the quote.
Confirm with us which evidence we can prepare for your own compliance assessment, while noting that independent auditors issue any formal opinion.

How to export your data from Discord