Your LinkedIn saved posts as JSON

CSV is for people. JSON is for everything else: a script, a backup you intend to restore, a model you want to hand a year of your own reading. It is the same library, shaped so nothing has to be parsed back out of a string.

The shape

Each saved post is one object. Media and author are nested rather than flattened into columns:

{
  "post_id": 8412,
  "text": "27 Claude shortcut hacks for faster prompts:",
  "link": "https://www.linkedin.com/posts/...",
  "posted_at": "2026-07-22",
  "labels": ["prompting"],
  "media": {
    "images": ["https://...", "https://..."],
    "video": null,
    "document": null
  },
  "author": {
    "name": "Ruben Hassid",
    "id": "...",
    "username": "...",
    "link": "https://www.linkedin.com/in/..."
  }
}

The differences from the CSV are the whole reason to pick it:

• `labels` is an array, not a ; -joined string.
• `media.images` is an array in carousel order, so slide three is images[2] rather than the third thing after a split.
• `media.video` and `media.document` are `null` when absent, not empty strings, so a truthiness check is enough.
• `author` is an object, so you can group by author.id — stable — instead of author_name, which is not.

Exporting it

Open Export to JSON and press export. Like CSV it streams back in the same request rather than queueing a job. A later history download regenerates the request from the saved post IDs and current stored records, so it is not guaranteed to be byte-for-byte identical.

The free plan exports a 20-post sample. That is genuinely enough to write your parser against before you decide anything.

When to use REST or MCP instead

The JSON download is a special export shape. The REST API and MCP tools expose the same library through their own request and response contracts. They also add capabilities such as pagination, search, and actions. Do not write an API or MCP client against the download example above.

• REST: use versioned endpoints when your application needs current data, pagination, or webhooks.
• MCP: connect a compatible client when an agent should search and retrieve only the posts it needs. Follow the MCP connection guide.

The download is the right tool for a one-off. Anything recurring belongs on the API.

Handing it to a model

A JSON export is a good context payload for an AI tool because the structure survives: the model can tell an author from a label from a link without you explaining the format.

Two things worth doing before you paste a year of saves into a chat window:

1. Strip what you do not need. post_id, author.id and author.username are for your code, not the model. Dropping them cuts the payload noticeably.
2. Filter first. "Summarize the themes in my 900 saved posts" is a worse prompt than the same question over the 40 you labelled for one project.

A backup that is actually restorable

JSON is the format to keep if the point is preservation rather than analysis. It holds the full post text, the media URLs and the author, which means a saved post survives the author deleting it, editing it or going private — none of which your LinkedIn list survives, because LinkedIn stores a pointer rather than a copy.

One caveat worth being honest about: media URLs are links, not files. If you need the images themselves to outlive the source, take the PDF archive as well, which renders the media into the document.

A backup you have never opened is a hypothesis. Export once, parse it once, then you know.