Claude Chat Exporter: Privacy-First Markdown Export for Claude.ai Conversations

Why a Bookmarklet Instead of a Browser Extension

Claude Chat Exporter is not a browser extension. It is a bookmarklet: a browser bookmark whose URL is a JavaScript snippet that runs in the current tab when clicked. The README offers a one-click install page at agarwalvishal.github.io/claude-chat-exporter/ where users drag a button onto their browser's bookmarks bar. Clicking that bookmark on any Claude.ai conversation triggers the export.

The bookmarklet approach avoids the browser extension permissions model and does not require approval through Chrome Web Store or Mozilla Add-ons. It also runs entirely within the user's existing browser session: the only network request it makes is to Claude's own backend using the user's existing session cookie. No separate server receives the conversation data.

The bookmarklet checks for updates automatically and shows a notice when a newer version is available. Users re-drag the button from the install page to update. The console script method is an alternative for developers who want to inspect or modify the code: paste the contents of claude-chat-exporter.js from the repository into the browser's developer console and run it directly.

How the Export Reads Claude's API

The export process is a single API call followed by a tree walk. The tool fetches the current conversation from Claude's internal API endpoint:

/api/organizations/{orgId}/chat_conversations/{conversationId}

The response contains the conversation title and every message in the thread. From this data, the tool reconstructs the currently visible branch by walking the message tree from the active leaf up its parent chain, which means a conversation where the user has regenerated a response exports exactly the branch shown on screen, not the newest branch by timestamp.

The tool then iterates over each message's content blocks in order. Text blocks contain Claude's original source markdown directly, with no HTML parsing or conversion. Artifacts (code, documents, diagrams), created files, and widget outputs are extracted in position and written as fenced code blocks inside the export. Images are embedded, documents are linked, and text file attachments are inlined. Hidden and system messages are skipped.

The output is a single Markdown file named after the conversation's API title. A YAML frontmatter block at the top includes the title, source URL, model, and export date. Each turn starts with a level-one heading ("# Human" or "# Claude") so Claude's own second- and third-level headings nest correctly beneath it.

Why API-Based Export Beats DOM Scraping

The README describes two competing approaches and is explicit about why it chose the API. The DOM-based approach drives the page, reads CSS selectors, and uses copy buttons to capture message text. It has three concrete failure modes: it only sees messages currently rendered in the viewport (long conversations export partially), it pairs human and Claude turns by DOM index (a regenerated response misaligns them), and it cannot reach artifacts, created files, or attachments because those elements have no copy button.

The API-based approach bypasses all three. Every message in the conversation is present in the API response regardless of whether it is visible on screen. The parent-chain traversal correctly handles regenerated responses. Artifacts and attachments are present as structured fields in the API response.

The trade-off is that the API is internal, meaning Claude's engineering team can change its schema at any time without publishing a changelog. The README acknowledges this directly, noting that someone has to track and implement those changes. The bookmarklet's update-check mechanism exists specifically because these changes happen.

Obsidian and RAG Pipeline Readiness

The YAML frontmatter and one-heading-per-turn structure are deliberate choices for downstream consumption. Obsidian's native linking and graph features work on files with consistent YAML metadata. A vault that stores exported conversations can link back to specific conversations, tag them by model, and search across them using Obsidian's full-text search.

For RAG pipelines, the heading-per-turn structure creates clean chunking boundaries. Each turn is a self-contained unit with a level-one header that identifies who sent it, making it straightforward to split the document into chunks by heading without mixing human and model text in the same chunk. The per-message timestamps from the API appear in the headings, adding temporal context.

The README notes that tables, math, code blocks, and complex formatting come through at full fidelity because the export reads Claude's source markdown directly rather than parsing the rendered HTML. A table that Claude generated will appear in the export as a properly formatted Markdown table, not as HTML.

Limitations: Internal API Dependency and Branch Behavior

The primary limitation is the dependency on Claude's internal API. The endpoint is not publicly documented, not versioned, and can change without notice. The README is candid that this is an ongoing maintenance problem. In practice, changes that break the export tend to coincide with significant Claude platform updates.

Branch handling requires an extra step. When a user has regenerated a response multiple times, the export follows the branch Claude is currently showing on screen, not automatically the latest or the first. To export a specific alternative branch, the user must first navigate to that branch using the arrows on the regenerated response, and then run the export. The README describes this behavior explicitly.

A comparable alternative for conversation archiving is copying the conversation to a text editor manually or using the export features that some AI interfaces build in natively. Claude.ai itself does not have a native export feature. Claude Chat Exporter fills that gap specifically for Claude.ai, while tools like ChatGPT Exporter fill a similar gap for other platforms using the same pattern of reading internal APIs.

Maintenance, License, and Privacy

The last push to the repository was on 2026-09-09. The repository is not archived. The project is maintained by a single author.

The README states plainly that the project's continued maintenance depends on sponsor support through GitHub Sponsors. The bookmarklet's update-check feature ensures that users with the older version will see a notice, but whether a breaking API change gets patched depends on the author's availability.

The license is MIT. No restrictions apply to commercial use, modification, or redistribution.

On privacy: the tool makes no external requests except to Claude's own backend over the user's existing session. No conversation data is transmitted to a third-party server, and the tool does not store anything after the Markdown file is downloaded.

Editorial conclusion

Claude Chat Exporter suits anyone who wants to archive Claude.ai conversations in a format that works with Obsidian, a RAG pipeline, or version control, and who wants the complete conversation including artifacts and attachments rather than a partial DOM scrape. The dependency on Claude's internal API is the main risk: Claude's backend changes without public versioning or notice, and the project's own README states that someone has to keep up with those changes, with maintainability depending on ongoing sponsorship. Verify that the bookmarklet shows an up-to-date version notice before relying on it for critical exports, and check the repository page for recent activity.

Frequently asked questions

Official sources

1. agarwalvishal/claude-chat-exporter on GitHub
2. Issues
3. License: MIT
4. Project website
5. README