Slipcase

What is a .slpc file?

A .slpc file bundles a document, image, or other file together with a description of what it is — who made it, what it's for, how it should be handled. That description travels with the file automatically: copy the file, email it, move it to another drive, and the description goes along for the ride.

Most files can't carry this kind of information on their own. A few formats let you tuck a little information inside, but only by opening up and altering the file itself, and most formats don't even offer that. File names can hold a hint at best. Notes kept in a separate file next to the original get separated the moment someone copies one and forgets the other. Information stored in a company database works fine until the file leaves that system, at which point nothing ties the two back together.

A .slpc file solves this by keeping the file and its description together in one package, without touching the original file at all.

How do I open one?

The short answer is Slipcase Open: install it, double-click the container, and the content file opens in whatever application you already use for that kind of file. Edit it there, save, and the edit goes back into the container. It is on the Microsoft Store, on macOS through Homebrew, and on Debian and Ubuntu through the Excelano apt repository. The other programs that read and write containers are on the implementations page.

No tool is required, though. A container is a ZIP archive, so any program that opens one of those opens a container: unzipping it gives you the content file and a small text file beside it. On a command line that is unzip report.pdf.slpc, and nothing has to be renamed for it. In a file manager:

Linux. Right-click, Open With, Archive Manager.

macOS. Right-click, Open With, Archive Utility. If it is not on the menu, the command line above works as it stands.

Windows. Right-click, Open with, and choose 7-Zip or whichever archiver you have. Windows' own Compressed Folders is not something that menu can offer, so with nothing else installed it is tar -xf report.pdf.slpc in PowerShell, or rename a copy to report.pdf.zip and open that.

A container is not encrypted and holds nothing hidden. If you were sent one and want to know what is in it before opening anything, unzip -l lists the members, and the flyleaf is plain text you can read.

Making one takes no special tooling

Write the flyleaf, then zip it together with the content file:

cat > slipcase.flyleaf.toml <<'TOML'
slipcase_version = "1.1"

[content]
file = "report.pdf"
TOML

zip report.pdf.slpc slipcase.flyleaf.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.flyleaf.toml and exactly one member named by the flyleaf's content.file key. It may hold any number of other members, which have no defined meaning and do not make it non-conformant. The flyleaf 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.

content.file

A string naming the content file. 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 recognize rather than dropping them.

What it does not do

Version 1.1 defines no signature or attestation mechanism, no encryption of its own, no aggregation of several content files into one container, no checksum or fixity key, and no vocabulary of descriptive metadata keys. A container binds one content file 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/vnd.excelano.slipcase+zip, registered in the vendor tree of RFC 6838. It supersedes application/x.slipcase+zip, provisional in the unregistered x. tree, which the registration records as a deprecated alias. The registration 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 flyleaf, 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.