How to export Mintlify docs without losing the sourceHow to export Mintlify docs without losing the source

Your team wants a backup of its Mintlify documentation, or needs the source files before evaluating another platform. Downloading the visible pages looks straightforward. But will that copy include the navigation, images, reusable snippets, and API descriptions needed to rebuild the docs?

To export Mintlify docs for editing or migration, preserve the documentation source and its dependencies first. Use published Markdown when you need readable page content. If you need a rendered site bundle, Mintlify documents a separate Enterprise static export. These outputs serve different jobs, so choose the one your next step actually needs.

This guide covers source preservation and export verification. It does not assume you are leaving Mintlify or that a destination can render every Mintlify component. We build Thally. The linked product documentation was reviewed on October 17, 2026.

Choose what you need to take with you

Your goal	Export route	What to verify
Keep editable docs or prepare for conversion	Copy the source repository or download its files	Correct branch, docs directory, configuration, assets, and external dependencies
Read or process published text	Mintlify's page-level Markdown output	Page coverage, audience-specific content, and authentication
Host a rendered Mintlify site bundle	Enterprise static export, with access arranged through Mintlify	Bundle contents, URL behavior, and features that depend on cloud services

A collection of readable pages is useful. An editable project also needs the instructions and dependencies that produce those pages. Keep that distinction in your export notes so a teammate does not mistake a text archive for a complete project backup.

1. Locate the source before downloading pages

Open Git Settings in the Mintlify dashboard. Record the repository, deployment branch, and documentation subdirectory. Mintlify's GitHub integration guide identifies this as the place to inspect the source connection.

If your organization already owns the repository, use that repository for the export. Confirm that pending editor work has reached the branch you intend to preserve. Record the current commit and compare a recently changed page with the live site. A repository can contain newer work than the published deployment.

If Mintlify hosts the repository

Mintlify documents a Clone option in Git Settings that copies the documentation into your GitHub account or organization. Its manual setup path also offers a ZIP download.

Download and inspect that ZIP before completing manual setup. Mintlify explicitly warns that manual setup permanently deletes content from the Mintlify-hosted repository. Keep the original copy until you have verified the downloaded files. Follow the current official steps, since the dashboard flow can change.

If your account cannot access the source or the download, ask the project owner to provide it. Treat the missing source as an unresolved export requirement.

2. Save a source snapshot you can identify later

For a repository in GitHub, select the deployment branch, open Code, and choose Download ZIP. Extract it into a new directory and retain the original archive. For a reproducible handoff, record the commit ID associated with the download, plus the repository URL, branch, docs directory, and export date.

GitHub's source archive documentation explains that an archive is a snapshot of a branch, tag, or commit. It does not include the full Git history. Branches and tags can move, while a commit identifies the source revision you reviewed.

If history matters, use a repository clone instead. GitHub's cloning guide covers that workflow. Keep the repository metadata with the clone. A ZIP is suitable for a file snapshot, but it cannot answer the same history questions as a clone.

For a monorepo, retain the surrounding directories until you have checked imports and asset references. Copying only the folder containing the page files can leave dependencies behind.

3. Inventory the files and dependencies

Find docs.json at the root of the documentation directory. Mintlify's settings reference describes it as the central configuration for navigation, branding, integrations, and API settings. Older projects may still have mint.json. Preserve the original configuration before attempting an upgrade or conversion.

Keep any configuration files referenced through $ref as well. A standalone docs.json is incomplete when its navigation or other settings resolve from separate files.

Use this inventory as a review worksheet. The paths below are examples of things to look for, not a required directory layout.

Material	Review question	What to retain
Markdown and MDX pages	Are all intended versions and languages present?	Page files, frontmatter, and original relative paths
Navigation and redirects	Which file controls page order and old URLs?	Configuration plus referenced configuration files
Images and downloads	Does each reference point to a local file or a remote host?	Local assets and a list of remote dependencies
Snippets and custom components	What does each page import or embed?	Source files and a list of renderer-specific behavior
API descriptions	Is the specification local or fetched from a URL?	Source descriptions, referenced files, and the reviewed revision
Dashboard configuration	What is configured outside Git?	A separate record of settings needed for reconstruction

Mintlify's navigation reference explains how page paths, groups, versions, and languages are represented in configuration. Preserve that structure even if the destination will organize it differently.

For API pages, inspect the OpenAPI setup and your project's configuration. A generated reference may depend on a specification rather than one authored MDX file per operation. If a spec or asset is remote, retain an authorized copy when appropriate and record its origin. Downloading a repository does not fetch every URL mentioned inside it.

Record dashboard-only settings separately. Keep credentials out of a general content handoff. The recipient needs to know which integrations require configuration, without receiving private keys in the docs archive.

4. Verify the copy before treating it as a backup

Open the extracted archive or clone in a fresh directory. Read the configuration and trace representative pages to their dependencies. A successful download only proves that you received files.

Check these cases against the source and the currently published site:

• A quickstart with code, links, and an image.
• A deeply nested guide with headings and anchor links.
• A page using tabs, callouts, snippets, or custom components.
• An API operation, including the specification it depends on.
• Each supported version or language included in the export scope.
• An old URL that redirects to a current page.

Record missing files, unreachable dependencies, and differences between the source revision and live deployment. Keep an explicit list of included and excluded content. Page counts help find omissions, but matching counts alone do not establish a complete export.

If you also need proof that the source renders, use the project's documented preview process in an isolated working copy. Compare its output with the live pages and retain the results. Do not describe an archive as a tested rebuild when you have only inspected its files.

When published Markdown is enough

Mintlify's Markdown export serves page content through a .md URL or a request accepting Markdown. This is useful for reading, indexing, or processing published text when you do not need the whole authoring project.

Verify the output you receive. Mintlify supports audience-specific content, so text visible to humans can differ from Markdown intended for agents. API Markdown can include specification content, with configuration controlling that behavior. Neither observation establishes that you have collected all source files or configuration.

If published text is all you can access, record that limitation. Keep page URLs and collection dates, check for authentication and missing pages, and avoid presenting the collection as a complete editable export.

When you need a static site bundle

Mintlify now documents an Enterprise static export. Access must be arranged with Mintlify. The documented process starts an export job, checks its status, and downloads the completed bundle through a time-limited link.

This produces rendered HTML, CSS, and JavaScript for hosting. It is a different deliverable from an MDX source archive. Review URL handling on the intended host, including .html paths, canonical URLs, and rewrite rules. Check which features require Mintlify cloud services in your environment.

We reviewed that documentation, but did not run the Enterprise export service. Use Mintlify's current instructions for the account-specific workflow and verify the resulting bundle before relying on it.

Hand off a verified export before converting it

A teammate should receive the source copy, its revision record, dependency inventory, and unresolved issues together. Keep the original export intact while conversion happens in a separate directory. Once a destination exists, compare navigation, components, assets, API pages, and redirects there before changing public URLs.

If you are evaluating Thally, prefer the Mintlify source repository when available because it preserves authored content and configuration. Thally also supports migration from a public documentation URL. Treat a URL import as a snapshot, then review the migration report, navigation, assets, components, and examples before publishing. Follow the Mintlify migration guide and URL migration overview for the supported paths. Our Thally and Mintlify comparison explains the ownership and publishing tradeoffs. Create a Thally workspace when you are ready to evaluate the destination with your own source.

Sources and verification

The primary sources linked beside each procedure were originally reviewed October 17, 2026 and checked again before first publication on October 26, 2026. The final review also checked Thally’s published URL migration workflow. GitHub's archive and clone documentation establishes the file-copy and history boundaries. Mintlify's documentation establishes the hosted-repository flow, configuration, Markdown output, and Enterprise static export. The inventory and verification worksheet are our recommendations. This article does not claim a completed customer migration or a tested Enterprise export. Read our editorial policy for sourcing and correction standards.