Real format support only

Converter sites routinely advertise hundreds or thousands of conversions. The number is usually arrived at by counting format pairs rather than formats: a site that handles thirty formats can describe itself as offering nine hundred conversions, because thirty inputs multiplied by thirty outputs is nine hundred. Most of those combinations are never used, and a good share of them produce output nobody would want.

The list above counts something different: formats with a working action behind them. If a format appears here, there is code in this site that reads or writes it, and a page where you can use it. Nothing is listed because it might be added later, and nothing is listed twice because it can be paired with a different output.

This makes the number smaller and it makes it checkable. Every row corresponds to a tool you can open. That is the trade FormatOS makes throughout, see tool limitations for the same approach applied to what the tools cannot do.

The deciding factor is not popularity or demand. It is whether the format can be read or written by code running inside a browser tab, because that is where FormatOS does its work, see how file processing works.

In practice that means a format is supportable when a JavaScript or WebAssembly engine exists that can handle it in the browser. PDFs are read and written with pdf.js and pdf-lib; images go through the browser's own canvas; ZIP archives use JSZip and zip.js; spreadsheets use ExcelJS; iPhone photos use heic2any; text extraction from scans uses Tesseract compiled to WebAssembly. Each of those is a real library doing real work on your device.

Video and audio are the clearest example of the other side of that line. Converting them properly requires a media engine that does not run usefully in a browser tab, the files are large, the work is heavy, and the codecs are not available. That is why no video or audio conversion appears anywhere on this site. It is a structural limit, not a backlog item, and no amount of demand changes it.

The same reasoning explains a few gaps that look arbitrary from outside. A format with no browser-capable library, or one whose only implementation is a desktop application, cannot be offered here honestly, so it is not listed at all rather than listed and then failing when you try it.

If a format you need is missing, say so through the Contact page. The useful details are the format itself, the direction you need (reading it, writing it, or both), and the actual task; what you are starting with and what you need to hand to whoever is asking for it. The task matters more than the format name, because there is often a route to the same result through something already supported.

In practice, a request for a format with a browser-capable library is realistic, and a request for one that needs a server engine is not, however reasonable the need. Where the answer is no, it will be a no rather than a silent backlog.