IFC stands for Industry Foundation Classes, a universal file format that lets different construction software share building model data with each other. Think of it as a common language: an architect working in one program can send a detailed 3D model to a structural engineer using completely different software, and the geometry, materials, and properties all come through intact. IFC is an open, non-proprietary standard, meaning no single software company owns or controls it.
Why IFC Exists
Modern construction projects rely on Building Information Modeling (BIM), where architects, engineers, and contractors each build detailed digital models of their portion of a project. The problem is that these professionals often use different software. Without a shared format, exchanging models means lost data, misaligned geometry, and hours of manual rework.
IFC solves this by acting as a neutral middleman. Rather than requiring every software vendor to build direct connections to every other vendor’s format, IFC provides one standardized structure that any program can export to and import from. It’s maintained by buildingSMART International, a global nonprofit that develops open digital standards for planning, design, procurement, assembly, and operation of buildings and infrastructure.
How an IFC File Is Structured
An IFC file doesn’t just store 3D shapes. It organizes a building the way you’d actually think about it: a project contains a site, which contains a building, which contains floors, which contain walls, doors, columns, and ducts. Each of those elements carries properties like material type, fire rating, load capacity, or cost. The relationships between elements are also stored, so the file knows that a particular window belongs to a specific wall on a specific floor.
This hierarchical structure is what separates IFC from a simple 3D geometry file. A generic 3D format might preserve the shape of a beam, but IFC preserves the fact that it’s a steel beam with a specific cross-section, connected to two columns, assigned to the second floor, and classified under a particular building code category.
File Formats and Extensions
IFC files come in several formats, each suited to different situations:
- .ifc (STEP Physical File): The most widely used format. It’s a plain-text file that any IFC-compatible tool can read, and it produces the most compact file size among text-based options.
- .ifcXML: An XML-based version that’s slightly larger (about 13% bigger) but easier to process with standard web and database tools.
- .ifcZIP: A compressed archive containing either an .ifc or .ifcXML file inside. It shrinks the file to roughly 17% of the original size, which matters when models reach into the gigabytes.
For most day-to-day file exchanges between team members, the standard .ifc format is the safest bet because it has the widest software compatibility.
IFC Versions
IFC has gone through several major versions, and two are especially relevant today. IFC 2×3 remains deeply embedded in projects worldwide. Its stability and maturity make it the default choice for many building-focused workflows, and as an open standard, it will always remain publicly available.
The latest published version is IFC 4.3, which became an official ISO standard (ISO 16739-1:2024) in March 2024. The big leap in 4.3 is support for civil infrastructure: roads, railways, bridges, earthworks, ports, and waterways all got dedicated data structures. Earlier versions were designed primarily for vertical construction (buildings), so this expansion was a major milestone for highway engineers, rail designers, and other infrastructure professionals who previously had no standardized way to exchange their models.
IFC 5 is in development, but buildingSMART has emphasized it’s designed to coexist with earlier versions, not replace them. Projects already running on 2×3 or 4.3 won’t need to migrate.
Model View Definitions
The full IFC schema is enormous, covering everything from HVAC systems to furniture placement. In practice, a structural engineer sending a model to a contractor for clash detection doesn’t need every piece of data the schema can hold. This is where Model View Definitions (MVDs) come in.
An MVD is a tailored subset of IFC built for a specific use case. It defines what data must be included, what should be excluded, how elements are structured, and how things like material assignments and classification systems are applied. For example, the Reference View MVD restricts geometry to simpler representation types and limits material definitions to layered sets, making it lightweight and reliable for coordination workflows. MVDs are essentially standards within the standard, each one fine-tuned for a particular exchange scenario.
How Teams Use IFC in Practice
A typical IFC workflow starts inside a BIM authoring tool like Revit or ArchiCAD. Before exporting, the team prepares the model: assigning each element the correct classification, enabling the relevant IFC properties, and organizing elements onto layers so that unnecessary objects (signage, vegetation, temporary items) can be filtered out. The user then saves a 3D view containing only the elements they want to share and exports it using a translator matched to the receiving software.
Before sending the file to a consultant or contractor, good practice is to open it in a standalone IFC viewer to verify that geometry, properties, and classifications survived the export correctly. Free viewers like BIM Vision, Solibri Anywhere, or the built-in viewers in many BIM platforms make this quick to check.
On the receiving end, the engineer or contractor imports the IFC file into their own software, where it becomes a reference model they can overlay with their own work. This is how clash detection works in practice: the architect’s walls, the structural engineer’s beams, and the mechanical engineer’s ductwork are all brought together as IFC models in a coordination tool, which flags anywhere those systems physically overlap.
Common Problems With IFC Exchange
IFC exchange doesn’t always go smoothly. The most frequent issues teams encounter include:
- Geometry shifts: Elements move slightly from their intended position during export, often caused by inconsistent coordinate systems between the sending and receiving software. In precision-critical projects, even millimeter-level shifts create real problems.
- Lost properties: Custom parameters, material data, or classification tags disappear during translation. This typically happens when property mapping is misconfigured during export, so data that existed in the original model simply doesn’t make it into the IFC file.
- Incorrect element types: A wall converts to a generic shape, or a beam loses its structural classification. Version mismatches between the exporting software’s IFC schema and the receiving software’s expectations are the usual culprit.
- Clash detection discrepancies: Teams notice that clashes detected in the original model don’t match what appears after IFC export, because tolerances and curved geometry get approximated differently during conversion.
Most of these problems trace back to export settings rather than flaws in the IFC format itself. Taking time to configure the translator, verify coordinate systems, and check the exported file in a viewer before distributing it prevents the majority of headaches.
Why IFC Matters for Your Project
The core benefit of IFC is freedom from software lock-in. Project data stored in a proprietary format can only be fully accessed by the software that created it, which becomes a problem when contracts change, teams rotate, or a building needs renovation 20 years later. IFC files remain readable by any compliant tool, indefinitely.
For project teams working across multiple firms, IFC eliminates the requirement that everyone use the same software. An architect on one platform, a structural engineer on another, and a mechanical contractor on a third can all collaborate through IFC without anyone switching tools. Government agencies and large owners increasingly mandate IFC delivery for exactly this reason: it ensures that the digital model of a building or bridge remains accessible and useful long after the original design team has moved on.