← Notes

File formats that don't lock you in

Some file formats will open in any software in twenty years; others only open in the app that made them, for as long as that app exists. Here is a practical list by type of work, and what makes a format safe to keep.

The file format is the part of your work that outlives every tool you use to make it. Apps get replaced, companies close, operating systems move on. Whether you can still open a document in ten years depends almost entirely on how it was saved.

What makes a format safe

Four properties, roughly in order of importance:

Documented. The specification is published, so anyone can write software that reads it. If the only description of a format is the code of one company's app, the format dies when that app does.

Widely implemented. Many independent programs read and write it. A documented format that only one app supports is safer than an undocumented one, but not by much.

Simple. Plain text, a straightforward image, a table of values. The more complex a format, the more likely other programs support only part of it.

Stable. It does not change incompatibly every few years.

A practical list

Writing

  • Plain text (.txt) and Markdown (.md) — the safest there is. Readable in any text editor, forever. Markdown adds headings, lists and links in a way that is still readable as plain text.
  • PDF — for finished documents that should look the same everywhere. PDF/A is a variant designed specifically for long-term archiving.
  • Office formats — .docx, .xlsx, .pptx are documented standards and widely supported, though complex layouts may not survive every program. OpenDocument (.odt, .ods) is an open alternative.
  • Riskier: app-specific formats of note-taking and writing apps, especially ones stored in a database or a proprietary bundle. Check what they export to.

Data and tables

  • CSV — a plain-text table that every spreadsheet, database and programming language reads. It loses formatting and formulas, which is exactly why it is portable.
  • JSON — for structured data that is more than a table.
  • SQLite — a database in a single, well-documented file, readable by a vast range of tools.

Images

  • PNG — lossless, universally supported.
  • JPEG — lossy, universal. Keep originals if you edit repeatedly.
  • TIFF — lossless, common for print and archiving.
  • HEIC — efficient and good quality, but not supported everywhere yet. Fine for storage on Apple devices; convert when sharing widely.
  • RAW camera files — each manufacturer's format differs. DNG is a documented RAW format some people convert to for archiving.
  • Layered project files — every editor has its own. Always keep a flattened PNG or TIFF of the final version as well.

Audio and video

  • MP4 and MOV with H.264 video — played by essentially everything. HEVC is more efficient and increasingly well supported.
  • WAV and FLAC — lossless audio. MP3 and AAC — lossy, universal.
  • Editing projects — timelines are app-specific in every video and audio editor. Keep a high-quality export of the finished work.

Personal data

  • vCard (.vcf) for contacts.
  • iCalendar (.ics) for calendars.
  • Mbox or EML for email.

These are old, plain-text-based standards, and every serious app in each category imports them.

Archives

  • ZIP — universal.
  • tar with gzip — universal on Mac and Linux.
  • 7z — documented and open-source, widely supported, a little less universal than ZIP.

Project files versus finished files

The most useful habit is to distinguish two kinds of file:

Project files keep your working state — layers, timelines, edit history, settings. They are almost always app-specific, because they record the app's own concepts. They are for continuing work.

Finished files are the result — the PNG, the MP4, the PDF. They should always be in an open, widely supported format. They are for keeping.

Save both. The project file lets you make changes next month; the finished file guarantees that you can see the result in ten years, whatever happens to the app.

A quick test for any format

Before committing years of work to an app, try:

  1. Export one piece of work to its most open format.
  2. Open that export in a different app — ideally on a different operating system.
  3. Check what was lost.

If the answer is "nothing important", you are safe. If the answer is "most of it", you are depending on that app.

How our apps line up

We try to follow the same rule we suggest. Where an app has a project format of its own — Garfi's .gvideo, Miyu Paint's .mpaint — it exists to keep editing state, and the finished work always exports to standard formats: MOV and MP4 from Garfi; PNG and JPEG, plus more in full access, from Miyu Paint.

Where no project format is needed, we do not invent one. Compact Contacts works on the contacts macOS already stores, and exports vCard and CSV. RenameDeck changes ordinary filenames and keeps no copy. Ziploom creates ZIP and 7Z, both documented formats readable by many other tools.

The aim is that no piece of finished work you make with our apps depends on our apps to open it.

Keep reading