Topic: chatgpt memory export

ChatGPT Memory Export — Where Your Memories Live in the Data Download (2026)

Q: Where does ChatGPT Memory data appear in the export ZIP?

Memory data lives in memory.json at the top level of the export ZIP — a JSON array of objects, one per stored memory entry. Each entry has a content field (the plain-text statement ChatGPT saved), an enabled boolean (false for memories you disabled but did not delete), and created_at / updated_at ISO-8601 timestamps. The same memories are rendered as a human-readable section in chat.html under 'My ChatGPT memories,' but memory.json is the machine-readable canonical source. If memory.json is absent from your export, Memory was disabled on the account before the export was requested.

Q: Does the export tell me which conversation generated each memory?

No — this is the single most significant gap in the memory export. The memory.json entries contain no source_conversation_id or source_message_id field. You can see what ChatGPT remembered, when the memory was created, and whether it is currently enabled — but you cannot directly trace any individual memory back to the conversation that produced it. The only workaround is reverse-lookup: full-text search your conversations.json for the memory's content string using jq or grep; if the memory was auto-saved verbatim from a specific exchange, the source conversation usually contains the same phrasing within a few tokens. This search is approximate, not deterministic.

Q: Are deleted memories included in the export?

Fully deleted memories — ones removed via 'Manage memory' or via the 'Delete all memories' action — are not included in the export. Memory deletion at OpenAI's end is a data erasure, not a soft delete, so the entries are gone from the source before the export is generated. Disabled memories (toggled off but not deleted) do appear in the export with enabled: false. This distinction matters for compliance: if you exported before deleting, the memory.json reflects the state at export time; a post-deletion export will have fewer entries.

Q: How does Memory export work for ChatGPT Team workspaces?

Team workspace admins typically disable Memory at the organization level via Workspace Settings → Data Controls. When Memory is disabled org-wide, individual members have no Memory to export and the memory.json in their personal export will be an empty array or absent entirely. Admins can re-enable Memory for the workspace, but most compliance-aware Team deployments leave it off because per-member Memory creates audit-surface complications. The workspace export (run by the admin) covers conversations and the audit log — not per-member Memory, because Memory is account-scoped rather than workspace-scoped. See the page on ChatGPT Team export differences for the full scope distinction.

ChatGPT's Memory feature saves persistent facts about you across conversations. When you request your data export, those memories are included — but the file format, what's missing, and how the export interacts with Team workspace policies are not documented in any obvious place. This page covers where memory data lives in the export ZIP, the schema for each memory entry, the one significant gap (no source-conversation linkage), jq recipes for extracting and searching your memories, how Team workspace Memory policy affects the export, and how ChatGPT's Memory differs from what WhyChose extracts.

TL;DR

Memory data lives in memory.json at the top level of the export ZIP — a JSON array of objects with content, enabled, and timestamps per entry. The source conversation that generated each memory is not linked in the export — this is the biggest operational gap. Fully deleted memories are not included; disabled (toggled-off) memories appear with enabled: false. For Team workspaces, Memory is usually disabled org-wide and the file will be empty or absent. To request the export: Settings → Data Controls → Export data → Confirm.

How to get the export that contains memory.json

The same standard data export that produces conversations.json also produces memory.json. There is no separate Memory-specific export. If Memory is enabled on your account:

Open ChatGPT → profile icon → Settings
Select Data controls (the exact label varies slightly between the web app and mobile)
Click Export data, then Confirm export
Wait for the email from OpenAI (usually minutes to a few hours depending on export size)
Download the ZIP, unzip, and look for memory.json at the top level alongside conversations.json, user.json, and chat.html

If memory.json is absent from the ZIP, Memory was disabled on the account before the export ran — either you turned it off yourself, a Team workspace admin disabled it org-wide, or you're on a plan tier that doesn't support Memory. The chat.html file in the same ZIP renders a human-readable "My ChatGPT memories" section; memory.json is the machine-readable version of the same data.

Full export walkthrough, including what else is in the ZIP and the common failure modes: How to export your ChatGPT history.

The memory.json schema

The file is a top-level JSON array. Each element is one stored memory:

[
  {
    "id": "mem_abc123",
    "content": "Prefers Python over JavaScript for backend services.",
    "enabled": true,
    "created_at": "2025-09-14T11:32:00Z",
    "updated_at": "2025-09-14T11:32:00Z"
  },
  {
    "id": "mem_def456",
    "content": "Works at a 12-person SaaS startup as the engineering lead.",
    "enabled": false,
    "created_at": "2025-07-02T08:14:00Z",
    "updated_at": "2026-01-18T16:05:00Z"
  }
]

Field reference:

Field	Type	Notes
`id`	string	Opaque identifier assigned by OpenAI. Stable across exports — the same memory will carry the same `id` in two exports taken at different times.
`content`	string	The plain-text statement of what was remembered. This is what ChatGPT surfaces in the Memory panel and uses as injected context in subsequent conversations.
`enabled`	boolean	`true` = currently active; `false` = disabled (toggled off by the user) but not deleted. Disabled memories still influence context in some configurations — check OpenAI's current documentation if relying on this for compliance purposes.
`created_at`	ISO 8601 string	When the memory entry was first created — either auto-saved by ChatGPT or manually added by the user.
`updated_at`	ISO 8601 string	When the memory entry was last modified. Equals `created_at` if the memory was never edited after creation.

One field that's notably absent: source_conversation_id. There is no pointer back to the conversation that triggered the memory save. This is the single most significant gap for anyone doing retrospective analysis of their Memory data.

The gap: no source-conversation linkage

ChatGPT's Memory system stores what it learned, but not where it learned it. The export reflects this: memory.json entries have no source_conversation_id, no source_message_id, and no suggested_at timestamp distinct from created_at. You can see that ChatGPT saved "Prefers Python over JavaScript for backend services" on 2025-09-14; you cannot see which conversation on that date produced it.

This matters for two ICP use cases:

Auditing memory accuracy. A memory that is stale or wrong (e.g., "works at a 12-person startup" after the team grew to 60 people) can be identified by checking the enabled field and the updated_at date, but the conversation where the wrong fact was first stated is not findable from the export alone.
Decision archaeology. Some memories encode decision-relevant facts: "decided to use Stripe over Paddle because VAT handling was too complex," "chose TypeScript for the new API layer," "planning to move to microservices in Q3." These are decision records embedded in Memory — but without a conversation link, the rationale context (the trade-offs, the alternatives considered, the date of the conversation) is lost.

The imperfect workaround: reverse-lookup in conversations.json. Run a case-insensitive search for the memory's content text against the conversation messages — if ChatGPT saved the memory verbatim (or near-verbatim) from an exchange, the source conversation usually contains the same phrasing within a short context window:

# Find conversations that contain text matching a memory entry
# Outputs conversation titles and IDs where the text appears
jq -r --arg q "TypeScript for the new API" '
  .[] | select(.mapping != null) |
  .mapping[] | select(.message.content.content_type == "text") |
  select(
    (.message.content.parts // []) | any(type == "string" and test($q; "i"))
  ) |
  .message.id
' conversations.json

This search is approximate: ChatGPT sometimes paraphrases when storing memories, and memories saved by the "auto-save" mode may not match any single message verbatim. For the decision-archaeology use case, it's a starting point — not a reliable audit trail.

jq recipes for working with memory.json

Assuming the export ZIP has been unzipped and you're in the directory containing memory.json:

# Count total memories
jq 'length' memory.json

# List all enabled memories (one content line each)
jq -r '.[] | select(.enabled) | .content' memory.json

# List disabled memories with date last updated
jq -r '.[] | select(.enabled == false) | "\(.updated_at)  \(.content)"' memory.json \
  | sort

# Find memories created in a specific year
jq -r '.[] | select(.created_at | startswith("2025")) | .content' memory.json

# Export as a readable Markdown list for archiving
jq -r '
  "# ChatGPT Memory Archive\n",
  (.[] | "- **\(.created_at[:10])** \(if .enabled then "" else "(disabled) " end)\(.content)")
' memory.json

The Markdown export recipe produces a readable list that survives outside the OpenAI ecosystem — useful for including in a personal knowledge base, sharing with a new AI assistant during onboarding, or simply archiving before deleting memories.

For the four-level search framework applied to conversations.json (the main chat archive alongside memory.json), see How to search your ChatGPT history.

Auto-saved vs manually managed memories

ChatGPT can add memories in two modes: auto-save (ChatGPT decides to save a fact without asking) and manual (the user opens "Manage memory" and adds an entry directly). The memory.json export does not distinguish between these two sources — both appear as ordinary entries with the same schema. The only signal is circumstantial: a manually added memory is likely to be phrased more precisely (as the user wrote it), while an auto-saved memory often reads like a summarized inference ("User prefers shorter explanations" rather than a verbatim quote).

Temporary memories — ones ChatGPT saved during a conversation in a Temporary Chat session — do not persist to the Memory store and are not exported. Temporary Chat sessions explicitly opt out of Memory writes; only standard conversation sessions contribute to the persistent Memory store reflected in memory.json.

Deleted vs disabled memories

The distinction matters for compliance and for anyone trying to reconstruct a complete memory history:

Deleted memories (removed via "Manage memory" → delete, or "Delete all memories", or via Settings → Data Controls → Delete all ChatGPT data) are fully erased before the export is generated. They do not appear in memory.json. If you exported before deleting, the old export shows them; a fresh export after deletion does not. There is no soft-delete; deletion is permanent.
Disabled memories (toggled off, not deleted) appear in the export with "enabled": false. These memories are retained in the account's Memory store but are not actively used in conversation context. They remain in the export because the data still exists — the user chose to suppress it, not erase it.

For GDPR or CCPA right-to-erasure purposes: the export confirms what's stored (both enabled and disabled entries). Requesting deletion of all data — not just "Manage memory" deletion — removes the memories and they will no longer appear in any subsequent export.

Memory export in ChatGPT Team and Enterprise workspaces

Memory behaves differently in Team and Enterprise plans, and the difference affects what appears in memory.json:

Memory is typically disabled org-wide in Team workspaces. Most compliance-aware Team deployments turn off Memory via Workspace Settings → Data Controls because per-member Memory creates audit-surface complications: members are leaving behavioral footprints across conversations that aren't captured in the workspace audit log. When Memory is disabled org-wide, members who run a personal export will find memory.json absent or an empty array — there is nothing to export.
The workspace export does not include per-member Memory. The Team export produced by a workspace admin covers workspace-scoped conversations, members.json, shared GPTs, and audit-log.jsonl. Memory is account-scoped rather than workspace-scoped — it lives in each member's personal account state, not the workspace. So even if Memory is enabled, the workspace export ZIP will not contain a memory.json; that data only surfaces in a member's personal export.
Enterprise workspaces with Memory enabled follow the same pattern: each member's personal export includes that member's memories; the workspace export does not aggregate them. Enterprise plans often disable Memory entirely for data-residency or regulatory reasons.

If you are a workspace admin auditing what personal data members hold that might be relevant to a compliance review: the personal export is the only path to memory data, and it requires the member to run the export themselves — or for the member to have authorized an admin-initiated DSAR via privacy@openai.com.

ChatGPT Memory vs what WhyChose extracts — different goals

ChatGPT's Memory and WhyChose's decision extractor both pull information out of your AI conversation history, but they serve opposite goals:

	ChatGPT Memory	WhyChose extraction
Purpose	Behavioral personalization — makes future responses better tailored to you	Decision audit trail — makes past reasoning queryable by you and your team
What gets saved	Personal facts and preferences ("works at a startup," "prefers Python")	Durable architecture and product decisions with the trade-offs and alternatives considered
Source linkage	Not tracked — no pointer back to source conversation	Always preserved — every extracted decision carries the original chat snippet and the conversation date
Team / org scope	Per-member personal account; not shared with teammates	Pro/Team tier exports to a shared decision log scoped by Project membership
What it misses	Decisions that weren't phrased as preferences; architectural calls; trade-offs and rejected alternatives	Personal preferences and behavioral context not expressed as decision-shaped exchanges

Practically: ChatGPT Memory is optimized for capturing context about you so ChatGPT can respond more usefully in the next conversation. WhyChose is optimized for capturing context about decisions so teammates (and your future self) can understand why the team made specific architecture and product calls. Some memories do encode decisions — "decided to use Stripe over Paddle because VAT handling was too complex" — and WhyChose's extractor would have surfaced the conversation that produced that fact as a decision record. But most memories are behavioral preferences, not architectural decisions; and most architectural decisions (the ones that matter for onboarding a new engineer or answering an investor's question) are not the kind of thing ChatGPT's Memory saves.

For teams that want both: memory.json is the fastest way to audit what personal context ChatGPT has been injecting into your conversations over time. The WhyChose extractor is the complementary step for recovering the architectural and product decisions that ChatGPT's Memory system never captured — because they were phrased as reasoning dialogues, not behavioral preferences.

Get early access