The IFC file format in BIM, short for Industry Foundation Classes, is an open and vendor-neutral data standard for sharing 3D building models between different software programs. Published as ISO 16739 and managed by buildingSMART, it lets architects, engineers, and contractors exchange geometry and project data without being locked into one proprietary tool.

When a structural engineer works in Tekla, an architect in Revit, and a facilities team in ArchiCAD, they all need to read the same building model. Native formats like RVT or PLN do not talk to each other directly. IFC solves that problem by acting as a common language every BIM application can write to and read from. Understanding how it works, what it stores, and where it falls short helps you avoid the data loss that often shows up during model handover.

What is the IFC file format in BIM?

IFC is a standardized, software-independent way to describe a building or piece of infrastructure as structured data. Instead of storing a model as a black-box file tied to one program, IFC records each element, a wall, a door, a beam, a duct, as an object with a defined type, geometry, properties, and relationships to other elements. That object-based structure is what separates BIM from plain 3D modeling.

The format was developed by buildingSMART International, the organization behind the openBIM movement. It has been published as the international standard ISO 16739 since 2013, which gives it legal and contractual weight on public projects across Europe, the Middle East, and parts of Asia where IFC delivery is now mandated.

How IFC fits into the BIM workflow

Building Information Modeling is a process of designing, building, and operating an asset using a shared digital model. The model carries not just shapes but data: materials, fire ratings, manufacturer details, thermal values, and cost codes. The trouble is that every authoring tool stores this differently.

IFC sits between those tools as a neutral exchange layer. A team can author a model in their preferred application, then export an IFC file that a partner imports into a completely different program. The geometry and most of the attached data survive the trip. This is the backbone of openBIM, where collaboration does not depend on everyone buying the same license.

If you are still choosing your authoring tools, our overview of free architecture software for students covers several programs with IFC import and export built in, including FreeCAD, ArchiCAD, and Revit.

What does an IFC file actually store?

An IFC file holds far more than a 3D shape. Each element is described as a typed object, so a wall is recognized as IfcWall rather than an anonymous block of geometry. Around that core, the format records:

• Geometry and spatial location of every component
• The spatial structure: site, building, storey, and space hierarchy
• Property sets such as fire rating, thermal transmittance, and load-bearing status
• Relationships, for example which wall hosts which window
• Materials, quantities, and classification references

This is why IFC supports tasks that plain CAD cannot, such as clash detection, quantity takeoff, and energy analysis. The data travels with the model.

IFC file types and encodings

IFC is a data schema, not a single physical file. The same model data can be saved in three different encodings depending on the workflow. Most people only ever see the first one, but knowing the differences helps when a partner sends a file you cannot open straight away.

Comparison of IFC file encodings

The table below summarizes how the three official IFC encodings compare in everyday use:

Encoding	Extension	Base standard	Best for
IFC-SPF (text)	.ifc	ISO 10303-21 (STEP)	Default exchange, compact and readable
IFC-XML	.ifcXML	ISO 10303-28	Web tools and XML-based data pipelines
IFC-ZIP	.ifcZIP	Zip compression	Large models, faster transfer by email or upload

In practice, the .ifc text encoding handles almost every exchange. The .ifcZIP version is just that same file compressed, often shrinking a model to a fraction of its size, and any compliant viewer unzips it automatically.

IFC schema versions you will meet

The IFC data model has evolved through several schema versions, and the version stamped in a file determines what data it can carry. Choosing the wrong export version is one of the quietest causes of failed handovers, so it pays to check before you send.

• IFC 2x3: released in 2007 and still widely required, especially where older validation tools and government templates expect it.
• IFC 4: a major update with improved geometry and richer property handling, suited to detailed building models.
• IFC 4.3: published as ISO 16739-1:2024, this version extends the schema to infrastructure such as roads, rail, bridges, and ports.

buildingSMART maintains the full release history and technical documentation on its IFC schema specifications page, which is the authoritative reference for which version supports which feature.

Why IFC matters for interoperability

The real value of IFC shows up at the seams between disciplines. A typical project might run an architectural model in one program, structural design in another, and MEP in a third. Without a neutral format, coordinating them means manual redrawing, screenshots, or expensive direct converters that break with every software update.

With IFC, each team exports its model and a coordinator pulls them into a federated model for clash detection and review. Because IFC is an ISO standard, it also protects long-term access to project data. A building outlives the software that designed it, and a facilities team in twenty years should still be able to open the as-built model. An open, documented format makes that possible in a way a proprietary file never can.

The open philosophy behind this is set out on the official buildingSMART openBIM page, which frames IFC as one part of a wider set of open standards alongside BCF for issue tracking and IDS for defining data requirements.

How to open and check an IFC file

You do not need expensive software to open an IFC model. A range of free viewers will display the geometry, list every object, and let you inspect the data attached to each element. This matters because the team receiving a model is often not the team that authored it, and they still need to trust what they are looking at.

Open-source viewers can read the model tree, isolate a single storey, and report the property sets on any selected wall or pipe. Most commercial coordination tools also import IFC directly, then federate several discipline models into one scene. When you open a file, three checks catch the majority of problems: confirm the spatial structure shows the right number of storeys, spot-check that key elements report their expected properties, and verify the model sits at the correct coordinates rather than drifting thousands of meters from the origin.

Coordinate placement deserves special attention. A surprising share of failed imports trace back to a model exported at the wrong base point, which sends it far from where the other disciplines expect it. Setting a shared project base point before export keeps every federated model aligned.

Where IFC falls short

IFC is powerful, but it is not magic, and assuming it carries everything perfectly leads to disappointment. Because it is a neutral translation, some authoring features have no exact equivalent in the schema and get simplified or dropped on export. Complex parametric families may export as static geometry, losing the rules that drove them. Vendor-specific data that has no matching IFC property can fall away unless it is mapped to a custom property set first.

Export quality also depends heavily on the authoring tool and the operator. Two people exporting the same model with different settings can produce files that behave very differently downstream. This is why teams agree on an exchange specification up front, defining exactly which version, property sets, and level of detail every IFC delivery must meet. Standards like buildingSMART's Information Delivery Specification exist precisely to make those requirements checkable rather than assumed.

Technical specifications and schema requirements should be verified against the official buildingSMART documentation for your specific project and contract.

IFC compared to native BIM formats

IFC does not replace native formats like Revit's RVT or ArchiCAD's PLN. The two serve different jobs. Native files keep the full parametric model, every constraint, family, and history step, and they perform best inside their own software. IFC strips that down to a documented, portable snapshot any tool can read.

Practiced teams keep both in mind. They author and edit in the native environment, then publish IFC at each milestone for coordination, regulatory submission, and archiving. Treating IFC as the delivery format and the native file as the working format gives you portability without giving up the modeling power of your main tool. If you want to study how well-structured native models are organized before exporting, our Autodesk Revit pack of full BIM models shows how production-ready projects are assembled and detailed.

For deeper technical reading on the encodings and schema history, the Industry Foundation Classes reference gives a well-sourced summary of how the format developed and how the .ifc, .ifcXML, and .ifcZIP encodings relate to the STEP standard.

The Bigger Picture

IFC is less a file you click and more an agreement the whole industry has made: that building data should outlive any single program. As public clients keep mandating open delivery and as IFC 4.3 stretches into infrastructure, the format is becoming the common ground where design, construction, and operations meet. The architects who treat IFC fluency as a core skill, not an export afterthought, are the ones whose models keep their value long after the project closes.