Slipcase

A .slpc file is a ZIP archive holding a payload file of any type together with a TOML metadata document describing it. The two become one file, so copying, moving, or sending the payload carries its metadata along.

Most files have nowhere to put metadata. Some formats have an embedded slot, but writing to it means modifying the payload, and a great many types have no slot at all. Filenames carry very little. Sidecar files sit beside the payload until someone copies one and not the other. Databases hold metadata well until the file leaves the system, and then the two are separated with nothing to reconnect them.

A container puts the description inside the same file as the thing it describes, and asks nothing of the payload: it is not modified, not re-encoded, and not required to have a slot of its own.

Making one takes no special tooling

Write the metadata document, then zip it together with the payload:

cat > slipcase.metadata.toml <<'TOML'
slipcase_version = "1.0"

[payload]
file = "report.pdf"
TOML

zip report.pdf.slpc slipcase.metadata.toml report.pdf

That is a conformant container, and unzip report.pdf.slpc recovers both members. Nothing about the format is reachable only through a library: a shell, an archive manager, or any language's ZIP module is enough to read one or to write one. That is a deliberate property rather than a happy accident, and the reasoning behind it is in the design document.

What is inside

A container is a ZIP archive with exactly one member named slipcase.metadata.toml and exactly one member named by the metadata's payload.file key. It may hold any number of other members, which have no defined meaning and do not make it non-conformant. The metadata document is TOML 1.1.0 in UTF-8, and the specification requires two keys of it:

slipcase_version

A string naming the version of the specification the container conforms to. It implies no compatibility at any level: an implementation written against one version cannot assume it can read a container declaring a higher one.

payload.file

A string naming the payload member. It is a plain filename and never a path — no separators, no . or .., no control characters.

Every other key is yours. The specification defines no vocabulary of descriptive metadata and assigns no meaning to any key beyond those two, so a container carrying keys it has never heard of is conformant, and an implementation is required to preserve the ones it does not recognise rather than dropping them.

What it does not do

Version 1.0 defines no signature or attestation mechanism, no encryption of its own, no aggregation of several payloads into one container, no checksum or fixity key, and no vocabulary of descriptive metadata keys. A container binds one payload to one description and stops there. The design document records why each of those was left out rather than deferred, which is a different claim and the more useful one to read before proposing that a future version take it on.

Extension and media type

The file extension is .slpc. The media type is application/x.slipcase+zip, provisional in the unregistered x. tree of RFC 6838; a vendor-tree registration for application/vnd.excelano.slipcase+zip was submitted to IANA on 29 August 2026 and is pending. The specification will name the registered type when there is one. The submission is in the repository, field for field.

Neither the extension nor the media type appears inside a container. The format reserves no magic bytes: a file is identified as a container by opening it and finding a conformant metadata member, which is a parse of untrusted input and is why §6 of the specification requires a reader to bound what it spends before it knows what it is holding.

The documents

Using it

The specification is dedicated to the public domain under CC0 1.0. Anyone can implement it, quote it, fork it, or embed the text, with no obligation to this project and nothing to ask permission for.

The most useful thing to send back is a question the specification cannot answer. The format is small and its rules are short, which makes it easy to read past a case that neither document decides — and two conforming implementations disagreeing about the same container is the clearest form of that. Open an issue on the specification repository; a case the specification leaves open is a specification bug rather than a matter of opinion.