A file format is a defined structure for encoding information as a sequence of bytes in a file, specifying how data is organized, which values mean what and how a program should interpret them. In software interoperability it is the contract between the program that writes a file and every program that later reads it: when both follow the same format, documents, images and data move between applications, operating systems and decades without loss.
A file format covers far more than its filename extension. It defines the header, metadata, data layout, compression, character encoding and version rules. Whether a format is open, documented and stable decides whether data stays portable or becomes locked to one vendor, which is why format choice is a long-term decision rather than a technical detail.
What a file format specifies
Most binary file formats begin with a signature, also called a magic number, a fixed byte sequence that identifies the format regardless of the filename. PNG files start with the bytes 89 50 4E 47, PDF files with %PDF-, and ZIP-based files with PK. Programs and operating systems use these signatures for reliable format detection, because extensions can be wrong or missing.
After the signature comes a header with version and global parameters, then the payload, which may be divided into chunks, records, pages or streams. A complete specification also states byte order (endianness), how text is encoded, how optional parts are skipped and how errors should be handled.
| Component | Purpose | Example |
|---|---|---|
| Signature | Identifies the format reliably | %PDF- at the start of a PDF |
| Header | Stores version and global settings | Image width, height and color depth |
| Metadata | Describes the content | Author, creation date, camera settings |
| Payload | Holds the actual data | Compressed pixels, text or audio samples |
| Index or directory | Allows fast random access | ZIP central directory, PDF cross-reference table |
| Checksum | Detects corruption | CRC-32 values in PNG chunks |
Text, binary and container formats
File formats fall into a few broad families, and each family has typical strengths. Text-based formats store data as readable characters, usually in UTF-8, which makes them easy to inspect and version-control. Binary formats store numbers and structures directly, which makes them compact and fast. Container formats wrap several streams or files in one package, often combining text and binary parts.
| Family | Examples | Strengths | Weaknesses |
|---|---|---|---|
| Plain text and delimited | TXT, CSV, TSV | Human-readable, universal | No types, ambiguous quoting and encoding |
| Structured text | JSON, XML, YAML | Self-describing, tool support | Larger files, slower parsing |
| Binary | PNG, MP3, SQLite | Compact, fast to read | Needs a specification or library |
| Container | ZIP, MP4, Matroska | Bundles many streams or files | Inner content still needs its own codecs |
| Package formats | DOCX, ODT, EPUB | Open XML parts inside a ZIP archive | Complex specifications |
Container formats explain a common confusion: an MP4 file may hold video in several different codecs, so a player that opens the container can still fail to decode the stream. The container format and the codec or content format inside it are separate layers of compatibility.
Open and proprietary file formats
The governance of a file format matters as much as its technical design. An open format has a published specification that anyone may implement without restrictive licensing, often maintained as an open standard by bodies such as ISO, W3C or IETF. A proprietary format is controlled by one vendor; its specification may be secret, partial or licensed, and other programs must rely on reverse engineering.
| Property | Open format | Proprietary format |
|---|---|---|
| Specification | Public and complete | Closed, partial or licensed |
| Independent implementations | Many, often interoperable | Few, frequently imperfect |
| Long-term readability | High, survives the original software | Depends on the vendor |
| Risk of vendor lock-in | Low | High |
| Typical examples | PDF/A, PNG, ODF, FLAC | Older closed office and design formats |
Openness is not binary in practice. Some formats are documented but patent-encumbered, and some vendor formats became de facto standards with public specifications. For archives and data exchange, the safest choice is a format with a complete public specification and several independent implementations.
Versioning and compatibility
File formats evolve, and each new version must decide how it treats older and newer readers. Backward compatibility means a new program can read files from older versions. Forward compatibility means an older program can at least open files written by a newer version, typically by skipping unknown chunks or elements it does not understand. Formats designed with extensible chunks, such as PNG, handle this gracefully.
Problems arise when a format relies on features that only one application supports. A document may open in another program but lose macros, fonts or layout details, which users experience as partial file compatibility rather than an outright failure.
Choosing a file format and avoiding pitfalls
Format choice should follow the purpose of the data: exchange, editing, archiving or performance. The decision table below gives common recommendations.
| Purpose | Suitable formats | Reason |
|---|---|---|
| Long-term document archiving | PDF/A, plain text | Fixed layout, open and self-contained |
| Editable office documents | ODF or Office Open XML | Documented structure, wide support |
| Tabular data exchange | CSV with UTF-8, Parquet | Universal reading or efficient columnar storage |
| Web and API data | JSON | Native support in nearly all languages |
| Lossless images | PNG, TIFF | No quality loss on saving |
- Trusting the extension: renaming a file does not convert it; real format conversion rewrites the data.
- Ignoring character encoding: a CSV file without declared encoding often breaks accented characters.
- Lossy round trips: repeatedly saving JPEG or converting between office formats accumulates loss.
- Parsing untrusted files carelessly: malformed files are a classic attack vector against parsers.
Understanding it simply
A file format is the set of rules for how information is stored in a file. It works like the layout of a paper form. If everyone agrees that the name goes in the first box and the date in the second, anyone can read the form correctly.
When two programs follow the same format, they can share files without problems. When the rules are secret or different, files open badly or not at all. Choosing a common, openly documented format keeps your information readable for many years.
Applied in practice
A city archive receives thousands of scanned council records every year, created in several office suites and scanning tools. Some older files are in a discontinued proprietary format that only one legacy program can open, and that program no longer runs on current operating systems.
The archivists set a policy: documents are stored as PDF/A for viewing, original text is kept as UTF-8 plain text for search, and tabular budgets are exported to CSV with a documented column schema. Every file is checked by its signature, not its extension, during ingest. Ten years later the records still open in several independent viewers, and the archive no longer depends on any single vendor’s software to read its own history.