“IFC” does not identify how a particular model is serialized or packaged. buildingSMART lists several IFC formats with different status labels and format-level trade-offs. That list can help you specify what to request, but it does not establish that a named application can read or write every form.
Compare the listed forms
The following descriptions reflect the buildingSMART IFC Formats page checked on 2026-09-26. Its table distinguishes official entries from provisional or experimental entries; it is a selected list, not a guarantee that every receiver supports each option.
| Form | Status on the page | What the format-level description says | What to confirm |
|---|---|---|---|
STEP Physical File (SPF), commonly .ifc |
Official | Clear-text STEP representation based on ISO 10303-21. buildingSMART describes it as the most widely used IFC format in practice and recommends it for the widest compatibility and smallest size in file-based import and export. | Confirm the receiver’s supported IFC release and any required view or information scope. The recommendation does not guarantee support or preservation in a particular application. |
ifcXML, .ifcXML |
Official | XML representation based on ISO 10303-28. The page highlights readability and availability of software tools. | Check whether the actual receiver accepts ifcXML, and whether that workflow needs a text-readable form. |
IFCZIP, .ifcZIP |
Official | A ZIP file may contain SPF or XML data. The container choice and the encoding inside it are separate details. | Confirm the receiver accepts IFCZIP and identify whether the embedded data is SPF or XML. Do not treat the ZIP suffix as proof that every project dependency is included. |
Turtle (.ttl) and RDF/XML (.rdf) |
Official entries associated with ifcOWL | These are RDF-oriented representations listed separately from SPF and ifcXML. | Confirm the intended schema mapping and receiver behavior; the listing is not a product-support or round-trip result. |
JSON (.json) and HDF (.hdf) |
Provisional/candidate | The page describes readability and tool availability for JSON, and hierarchical indexed access for HDF. | Keep their provisional/candidate status visible and check the exact implementation before specifying either. |
SQLite (.sqlite) |
Experimental/unsupported | The page describes a relational database option for indexed access to large models. | Treat this status as experimental/unsupported on the cited page; do not assume it is an ordinary file-exchange choice. |
These are format-level distinctions. An IFC serialization does not, by itself, identify the model’s schema release, view, required properties, or the information a particular translator will preserve. Record those separately; see the scope inside an IFC format.
Choose for the exchange context
For a file-based import or export, buildingSMART recommends SPF for the widest compatibility and smallest size. Apply that as a format-level starting point, then verify the receiver’s own documentation for the exact IFC release and workflow. If readability, an XML toolchain, or a package container is required, consider ifcXML or IFCZIP only after the sender and receiver confirm the form they use.
The page also says that web-service clients and servers may negotiate among the listed formats. That describes a service exchange; it does not mean a local file handoff can rely on automatic negotiation. In either case, record the agreed serialization rather than writing only “IFC.”
Keep the container and model scope distinct
An .ifcZIP file may wrap SPF or XML, so the outer container does not replace the inner encoding. Neither file form settles which IFC release, model view, or project information requirements apply. If required data is missing, a different serialization alone does not restore it.
For a practical handoff record, include:
- the exact serialization and filename extension;
- the IFC release and applicable view or information requirement;
- whether the file is SPF, ifcXML, or a container with an identified inner form;
- the sender and receiver products and releases, with the relevant support references; and
- the receiver-side checks that will show whether the intended model information is usable.
Keep format selection separate from product support and acceptance. See directional support for reading implementation claims and containers and resources for the broader distinction between a file, a container, and a complete delivery package.
Key points
- IFC-SPF, ifcXML, and IFCZIP are different official file forms; an IFCZIP may contain SPF or XML.
- buildingSMART recommends SPF for the stated file-based compatibility and size criterion, but this is not a receiver guarantee.
- The page labels JSON and HDF provisional/candidate and SQLite experimental/unsupported; keep those statuses attached to the claim.
- Serialization does not replace recording the IFC release, view, implementation support, or acceptance checks.