Discord Package turns the data export request into a dashboard you can show people

A data export you already have, rendered in a browser

Discord Package is described as a detailed Discord data package explorer designed to help users visualize the data Discord collects, and the README puts it as a visualization tool for your Discord data package.

The framing matters. The input is the archive Discord sends you when you request your data, and the output is a set of interactive views over it. There is no account connection, no API integration and no scraping of the live service in what the README describes.

The About section states the goal plainly: ever wondered what data Discord collects. The tool lets you visualize your data package, share selected insights with friends and discover patterns in your usage.

The homepage is discordpackage.com, and there is a hosted instance you can point at, with the domain controlled by an environment variable so you can run your own copy. The primary language is TypeScript, the licence is GPL-3.0, and the repository is not archived with the last push on 2026-07-27. The recent releases are Discord Package Version 4.1.0 from January 2026, 4.0.0 from February 2025 and 3.0.0 from April 2023.

The project also credits Andros2091 for the original source, the discord-data-package-explorer repository, so this is a maintained fork of an earlier tool rather than something that started here.

What the export contains, as the tool reads it

The Key Features section lists the categories of data the tool surfaces, and this list is effectively a map of the export format.

At the top level there is user information and settings, device preferences and server details, platform connections, Discord spending and Nitro gifts, messaging patterns and statistics, guild membership details, bot interactions, and language analysis covering favourite words and links.

The expanded statistics go further. Message analytics covers top DMs and channels, character count, time spent analysis, word frequency and link sharing patterns. Platform usage covers login patterns, device usage and feature interaction. Social interactions covers friend requests, guild participation and voice channel activity.

Two entries are worth a second look because they are the most sensitive. Platform connections and login patterns describe where and when the account has been used, which is a close reconstruction of someone's location history from their account. Discord spending and Nitro gifts is financial history. And message analytics with time spent analysis and top DMs describes the contents and cadence of private conversations.

That is the same data Discord already holds and hands over on request. The tool's job is to make it legible, and the visibility cost of that legibility is the thing to think about before sharing a screenshot of a dashboard.

Client side processing, and what that claim commits you to

The privacy feature is stated as no data storage, pure client side processing.

The dependency list backs the second half of that claim. papaparse is a CSV parser that runs in the browser, fflate is a compression library, and there is no server-side data store in the repository, no database configuration and no API credentials in the package manifest. The data is parsed and rendered where the file already is, in your browser.

That is a genuinely better privacy posture than a hosted analyser that uploads your export to a server, and for this data it is the right default.

Two things follow that the README does not spell out. First, the cost moves to your machine. A multi-gigabyte export has to be parsed and held in browser memory, so the performance on a large package depends on the device rather than on a server the author operates. Second, the hosted instance at discordpackage.com is still a third party holding your file while it is open, which is a different trust question from the client side processing claim. The two are compatible, since the processing is client side, but the file still passes through a server in the hosted case, and that is a question about the host operator rather than about the code.

The library choices also tell you what the views are built from. Highcharts and its React wrapper do the charting, framer-motion and react-particles handle the animation, and jotai is the state manager, which is why the dashboard can filter across views without a data layer underneath.

Installing it, and the domain variable you have to change

There is no install command in the README, because this is a web application you host rather than a package you add to a project.

The one configuration step is the environment variable. When hosting locally or externally, you have to change the NEXT_PUBLIC_DOMAIN environment variable in the .env.local file to your domain, or it will use the default domain https://discordpackage.com.

- Local: Just edit it manually
- External: You need to customize it via the provider dashboard settings.

The repository ships a .env.local file, so the value is there to be edited rather than created.

For a local run, the scripts in package.json are the usual Next.js ones, with dev running the development server, build producing a production build, start serving the out directory with npx serve@latest, and lint running next lint.

For Docker there are two commands.

- Run `docker build -t discord-package-explorer .` to build the image.
- Run `docker run -p 3000:3000 discord-package-explorer` to start the app.

The README closes that section with the phrase and you're good to go. What that leaves unsaid is that the container serves the application on port 3000 and nothing else, so it should not be exposed to a network you do not control.

The Dockerfile and compose file, and a deployment that is a static export

The Dockerfile is a standard multi stage Next.js build, and one detail in it is worth reading because it explains the start script.

FROM node:20-alpine AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY package*.json ./
RUN npm install -g pnpm && pnpm install
FROM node:20 AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm install -g pnpm && pnpm build
FROM node:20 AS runner
WORKDIR /app
ENV NODE_ENV production

The runner stage copies .next/standalone and .next/static and runs node server.js, which is the Next.js standalone output mode. The build stage also copies next.config.js and public/ into the runner, and the final image adds a non-root nextjs user with uid 1001, exposes port 3000 and sets PORT 3000.

The docker-compose.yml is three services of configuration: a service named nextjs, a port mapping of 3000 to 3000, and a build section pointing at the local context and the Dockerfile.

services:
  nextjs:
    ports:
      - 3000:3000
    build:
      context: .
      dockerfile: Dockerfile

There is a second deployment target as well. The repository has a netlify.toml, a CNAME file and an app.json, plus a netlify-plugin-submit-sitemap dependency in the dev dependencies, and a scripts/ directory. The start script serving the out directory with npx serve suggests the build is configured to produce a static export, which would explain the Netlify path as well as the Docker path. The README does not describe the Netlify configuration, so that is something to read in the repository rather than in the documentation.

Where Discord Package is the wrong choice

Three cases, and the first is about what the tool is not.

It is not a Discord client, a moderation tool, an account management utility or a live dashboard. It works on an export file that Discord sends you on request, so anything that needs to run continuously against a server account or a guild is out of scope. The repository has no Discord API client in the dependency list, no token handling, and no bot logic beyond visualising what the export already contains.

The second is that the tool is for your own data, or for data you have been explicitly given. The README suggests sharing selected insights with friends, which is fine in principle and dangerous in practice, because the package contains private messages, login history and purchase records, and the visualisation makes the sensitive parts more quotable rather than less. A screenshot of a time spent analysis chart is still your account's behavioural history, and a shared link to a hosted instance may put the file on someone else's server for the duration of the visit.

The third is scale. Client side parsing of a large export depends on the browser of the person opening it, and the README publishes no guidance on package size, parse time or memory use, so a multi-gigabyte account is a case you have to try rather than a case the documentation covers. The Docker route helps if you want to do the parsing on your own hardware rather than in a shared browser tab.

Editorial conclusion

Adopt Discord Package if you have requested your Discord data and want to actually read it, or if you build tooling around the export format and want a visual reference for what the package contains. Do not adopt it for a live account integration, since the tool works on an export file you supply rather than connecting to an account. Before you host it anywhere, set NEXT_PUBLIC_DOMAIN in .env.local, and if you self-host, remember that the package contains your private messages, so the Docker route is the one to keep local.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. peterhanania/Discord-Package on GitHub
3. Project website
4. README
5. Releases