The shopping cart deserves to be a file

Here is a small thing that has quietly annoyed me for years, and which I only recently worked out how to name.

A shopping cart is a document. It is a list of things you intend to buy, from a particular seller, at particular prices, with tax and shipping attached.

That is a document by any reasonable definition. And yet it is the one document in my working life that I am never allowed to keep.

It lives in a cookie, or in a server-side session tied to one login on one browser on one device. The moment any of those three things changes, it is gone. (Try opening your cart from your phone on the shop you were browsing on your laptop an hour ago. Good luck.)

For most people, most of the time, this doesn't matter. You fill a cart, you pay, the cart's job is over.

But I don't mostly shop that way, and neither does anyone doing procurement. When you are assembling a bill of materials, collecting quotes, or comparing the same basket of goods across three suppliers, the cart is the deliverable. It is the thing you want to save, reopen next week, hand to a colleague, or turn into a purchase order.

And there is simply no standard way to do any of that.

So I wrote one. It's called .cart — an open, vendor-neutral file format (plain JSON, UTF-8) that describes the contents of a shopping cart as a portable file you actually own.

Why now, and not five years ago

The honest answer is: agents.

A year ago, "export your cart to a file" would have been a lovely idea with no realistic path to adoption. It would have required every storefront on earth to add an export button. That's a non-starter.

But the ground has shifted. A browser-based agent — or an MCP server — can already read any cart page today. It can see the line items, the quantities, the prices before and after VAT.

What's been missing isn't the ability to read a cart. It's a standard shape to write it into once you've read it.

That reframes the whole problem. .cart doesn't need buy-in from Shopify or Magento or the custom storefront your industrial supplier built in 2011. It needs an agent that can read a page and serialise what it sees.

The format is the interoperability layer that sits between "an agent looked at a cart" and "you have a file you can diff, merge, re-price, or turn into an RFQ."

The current state of the art for moving a cart from one place to another is taking a screenshot and asking someone (or some model) to recreate it by hand. That is inefficient, error-prone, and completely unnecessary. We can do better than a photograph of a list.

What's actually in the format

I designed .cart around a few stubborn opinions.

It's tax-aware on purpose. Every price is expressed both before and after VAT, because B2B and B2C readers really do need different views of the same cart. A consumer wants the number they'll pay; a purchasing officer wants the ex-VAT figure that lands in the ledger. Rather than pick a side, the file carries both — plus the scheme and rate — so nobody has to reverse-engineer the maths later.

It's self-describing. A .cart file carries the merchant, the currency, the source URL, and the moment of capture. Open one in six months on a different machine and it still means something on its own. Which is the whole point of calling it a document rather than a cache entry.

It's lossless where it can be, and graceful where it can't. Vendor-specific oddities don't get thrown away; they get parked under an extensions block, so nothing you scraped is lost even if the core spec has no field for it. Consumers ignore what they don't recognise, which keeps the format forward-compatible instead of brittle.

And it's boring, deliberately. Field names are snake_case, timestamps are ISO 8601 with a timezone, currencies are ISO 4217, monetary amounts are plain numbers in major units. There is a JSON Schema so a file can be validated rather than trusted.

None of this is clever, and that's the feature. A standard that tries to be interesting is a standard nobody implements.

Where this goes

The most useful verb, for me, is transform.

Once a cart is a file, turning it into a purchase order or a request for quotation is a mapping exercise, not a retyping exercise. Comparing the same basket across vendors becomes a diff. Watching a supplier's prices drift over a quarter becomes a time series.

All of that is downstream of one small decision: treat the cart as something you can save.

It is very much a v0.1 draft proposal, and I'd like it torn apart. If you do procurement, or build storefronts, or write shopping agents, and you think I've modelled tax wrong or missed an obvious field — tell me. That's what the "request for comments" in the spec is there for.

The full specification, JSON Schema, and a worked industrial-supplier example are in the repository:

→ github.com/danielrosehill/Dot-Cart