I've been building Chrome extensions that help people save and organize conversations from AI platforms.
What started as a relatively straightforward idea — exporting AI chats into Notion, Markdown, or PDF — eventually turned into a much more complicated engineering challenge.
Today, my project, AIExportHub, supports conversations from six AI platforms:
At first glance, exporting a conversation sounds simple. Read the messages, convert them into another format, and save the result.
But once you start supporting multiple platforms, long conversation histories, Projects, images, generated files, and different output formats, things become much more interesting.
Here are some of the lessons I've learned while working on this project.
The first major challenge is that every AI platform structures its conversations differently.
Even though ChatGPT, Claude, and Gemini all look like chat applications, the way they represent and expose conversation data can be quite different.
A conversation isn't necessarily just an array of user and assistant messages.
Depending on the platform, it might include:
And these structures can change when platforms update their interfaces.
This creates a fundamental problem: you can't assume the same extraction logic will work everywhere.
One useful way to approach this problem is to think about two separate concerns.
The first is collecting and interpreting conversations from each platform.
The second is converting that content into the user's desired format.
A conceptual export pipeline looks like this:
This separation matters because otherwise every new platform multiplies the number of special cases throughout the exporter.
If the source parsing and output generation are tightly coupled, a small change to one platform can affect several export workflows. Lesson learned: Treat platform-specific parsing as a separate engineering problem from document generation.
Text is only part of a modern AI conversation.
People upload PDFs, screenshots, spreadsheets, and source files. AI platforms also generate images, documents, code assets, and other downloadable files.
When a user exports a conversation, they often expect those attachments to be preserved alongside the text.
This is where things become complicated.
Some assets are accessible only within the user's authenticated session.
Others use temporary or protected download URLs.
A link that works inside an open ChatGPT conversation may not behave the same way when accessed from an unrelated browser extension context.
For example, AIExportHub handles supported protected ChatGPT-generated files through the connected, signed-in ChatGPT tab. The important principle is that the original source session may be necessary to retrieve an asset successfully.
Simply extracting a URL and attempting to download it later isn't always reliable.
Even with the correct session, an exporter can't necessarily recover a file that the source platform no longer provides.
This is an important limitation.
A backup tool can preserve content that is accessible at export time, but it cannot guarantee recovery of deleted or expired source assets.
For that reason, I think backup tools should distinguish between: Reporting these cases accurately is better than displaying a generic success message.
Markdown is one of my favorite export formats because it's portable.
You can open it in Obsidian, VS Code, or almost any text editor.
But generating useful Markdown from AI conversations involves more than joining messages together.
Consider a conversation containing:
If you simply extract the visible text, much of the original structure can disappear. A code example might lose its formatting. A mathematical expression might become difficult to read. An image could turn into a broken link.
The goal isn't just to preserve the words.
It's to preserve enough structure that the conversation remains useful outside the original website.
Suppose you export a conversation as Markdown and download its images separately.
If the Markdown file still references temporary URLs from the original AI platform, those references may stop working later.
For local archives, a better approach is to store supported assets alongside the Markdown document and use local relative paths.
For example, a Markdown note and its attachments might be organized like this:
conversation.md`` assets/diagram.png``assets/reference.pdf
The note can then reference the local image instead of relying entirely on the original hosted URL.
AIExportHub supports local asset folders and link rewriting for available images and attachments.
This is especially useful for Obsidian users who want to maintain a portable knowledge vault.
Lesson learned: A Markdown export should be treated as a portable document with its dependencies, not just a text file.
Exporting one conversation and exporting hundreds of conversations are very different challenges.
An individual export is usually a relatively short operation.
A bulk export can involve many conversations, different content types, numerous attachments, and repeated requests to the source platform.
Several things can go wrong during a long-running job:
One failed conversation shouldn't necessarily invalidate an entire batch.
Imagine exporting 500 conversations.
If the process fails on conversation 430, restarting everything from the beginning would be frustrating. A more reliable workflow needs to account for individual items rather than treating the entire operation as one all-or-nothing task.
That means keeping track of concepts such as:
AIExportHub includes batch progress, configurable delays, cancellation, retry options, and the ability to skip previously exported items in supported workflows.
These features may not look as exciting as a new export format, but they become essential when processing large histories.
One temptation when building a bulk exporter is to make everything run as quickly as possible.
But a high request rate can cause more failures rather than faster completion.
For long-running exports, controlled pacing and graceful recovery are often more important than maximum throughput.
If the source platform starts rejecting requests, continuing to send more requests immediately may only make the situation worse.
A reliable exporter needs to recognize such limits and avoid turning a temporary restriction into hundreds of repeated failures.
Lesson learned: Reliability, resumability, and accurate progress reporting are core features of a bulk export tool.
AI platforms are no longer limited to independent conversations.
We now have features such as ChatGPT Projects, Claude Projects, Gemini Gems, Genspark Hubs, and other ways of grouping related work.
These features create another challenge.
A conversation can belong to a larger collection with its own context and organization.
If you export only the messages without preserving any collection information, you may lose an important part of how the knowledge was organized.
For example, imagine a Claude Project containing multiple discussions about the same application.
Saving all those conversations into one flat folder without any Project context makes it harder to understand their relationship later.
A useful export should preserve available collection metadata and provide a sensible folder or database structure.
However, there's an important distinction:
Exporting conversations from a Project is not necessarily the same as backing up the entire Project.
Project instructions, settings, independently uploaded files, and other platform-specific information may require separate handling.
I think being explicit about these limitations is essential, especially when users rely on backups for important work.
Another lesson is that the destination format changes what a good export looks like.
The same conversation might be used in several different ways.
Markdown works well for users who want files they can keep, edit, search, and organize locally.
It's particularly useful for Obsidian workflows, source-code notes, and long-term archives.
The main challenges are preserving structure, managing attachments, and keeping links functional.
Notion is useful when conversations need to become part of a structured workspace.
A conversation can include information such as its title, source platform, URL, timestamps, and related collection.
Instead of storing everything as unrelated documents, users can organize conversations in databases and project pages.
But exporting to Notion introduces another set of considerations.
The user needs to authorize the destination workspace, and the integration needs permission to access the selected pages or databases.
Media uploads and long conversations also require different handling from a simple Markdown download.
PDF is useful when the goal is to preserve a readable document.
However, a PDF isn't automatically a complete backup of every associated file.
For example, images may be embedded in the document while other supported attachments need to be downloaded separately. Formatting also matters. Long conversations, tables, code blocks, and mathematical expressions can make PDF rendering surprisingly difficult.
Lesson learned: Different export formats require different preservation strategies. One output format cannot perfectly serve every use case.
AI conversations can contain sensitive information.
People use AI assistants for work, research, code reviews, personal notes, and internal documents.
When building an exporter, it's important to consider where that information goes during processing.
For AIExportHub, Markdown and PDF exports are generated in the browser without requiring an intermediate cloud workspace.
For Notion exports, users authorize their own Notion workspace and choose the destination.
There are still interactions with the original AI platforms, of course, because the browser needs to retrieve the conversations and available assets.
So local-first doesn't mean the browser never communicates with an online service.
It means avoiding unnecessary intermediate services for local file generation.
I think this is a useful design principle for browser-based productivity tools.
Users should understand which services access their data and why.
One particularly frustrating part of maintaining browser extensions is that the websites they interact with can change without warning.
A conversation identifier might be exposed differently.
An interface element might be moved.
A content structure might be updated.
An attachment retrieval flow might start behaving differently.
From the user's perspective, the extension simply stops working.
From the developer's perspective, the problem may originate in a platform you don't control.
This is why real user feedback has been so valuable.
A report such as "the export failed" is a starting point, but it's much easier to investigate when you can identify:
In some cases, a failure happens only with a particular conversation structure or attachment type.
Reproducing those cases is often the hardest part of debugging.
This has reinforced one principle for me:
An exporter that depends on changing third-party platforms is never really finished.
Maintenance and compatibility testing are ongoing parts of the product.
These challenges are what led me to keep expanding AIExportHub.
It's a Chrome extension for exporting conversations from ChatGPT, Claude, Gemini, Perplexity, Grok, and Genspark.
Depending on the source platform, it supports:
It's free to try, with some advanced features requiring a paid plan.
I'm still working on improving compatibility, long-running exports, and how different types of content are preserved.
The biggest takeaway from this project is that exporting AI conversations isn't simply about saving text.
It's about dealing with changing platforms, preserving structured content, maintaining access to available files, and making the final result useful outside the original application.
Working on an AI conversation exporter has taught me quite a bit about browser extensions and the challenges of building tools on top of third-party web applications.
If I had to summarize the most important lessons, they would be: There's still plenty to improve, especially as AI conversations become more complex and platforms introduce new features.
But I believe the underlying problem is worth solving.
AI conversations are becoming an important part of how we work and learn. We should have practical ways to preserve and reuse that knowledge beyond a single chat interface.
I'm curious about other developers' experiences:
Have you built a Chrome extension that depends on a third-party website's changing interface?
How do you handle breaking changes, authenticated downloads, or large background operations?
I'd love to learn how others approach these problems.
Thanks for reading!
— Jack
Indie developer building AIExportHub.