Knowledge base · CAD packages
What is an IFC file, and what is not in it
In short
- An IFC file is an open, vendor-neutral format for building models, but it looks complete even when parts are actually missing.
- It usually carries geometry, element types, hierarchy and basic properties, but not detailed drawings, dimensioning, or package-specific formulas and families.
- A viewer shows an export exactly as it was made, so it helps to agree the version, disciplines and properties beforehand.
You get sent a file, the extension is .ifc, and you are not quite sure what to do with it. It happens in the office just as much as on site: a contractor forwards the model, a subcontractor delivers his part of the installation, or the draughtsman sets it up so the team can take a look. You open it, a 3D model appears, and the first question is usually not how to open it, but what is in it.
That is a fair question, because an IFC file looks complete but rarely is. It carries the shape and the structure of a building, but not necessarily everything the draughtsman had on his screen while building the model. Anyone who does not know that difference sometimes expects things from an IFC that were never in it: a dimension that is missing, a detail you cannot find, a part with no name.
Below is what an IFC file is, what is usually in it and what is not, and why that is the case.
An IFC file is not a CAD package
IFC stands for Industry Foundation Classes, an open file format for building models. It is maintained by buildingSMART International and was deliberately set up to be vendor-neutral: no single software house owns the format or decides on its own what goes into it. Packages such as Revit, ArchiCAD, Tekla Structures, cadwork, SketchUp or Vertex BD can all export to it.
Important to remember: nobody draws directly in IFC. You draw in your own package and export to IFC at the end. The file is therefore a snapshot of the model at the moment of export, not a living document you can keep working in. What you do with such a file on the shop floor is covered on the page about IFC files on site.
Not every IFC is the same IFC
Different versions of the format exist; IFC2x3 and IFC4 are the best known. Most CAD packages let you choose which version to export to, and that is not a minor detail: an older or newer version can support different things. Meanwhile buildingSMART is also working on newer versions, so the format keeps moving.
There is also the concept of a view definition, or MVD: an agreement on which subset of the model is included in an export, such as a coordination view for coordination between disciplines. Together with the version, that also determines how much of the model ends up in the file.
What is usually included
A typical IFC export contains the geometry: the shape and exact position of every part in three dimensions. Each element also carries a type, so a wall is recognisable as a wall, a beam as a beam and a door as a door, rather than a nameless shape. On top of that sits a hierarchy that orders the project from project to site, to building, to storey, and usually a set of properties per element: dimensions, material, type, sometimes an identification number.
That is also why an IFC is usable outside the package it was made in: structure and meaning travel with the file.
What is often missing
This is the heart of the matter, and the reason people on site are sometimes caught out. The table sets out, briefly, what you can and cannot expect.
| Usually included | Usually not included |
|---|---|
| Shape and position of every part | Finished 2D detail drawings |
| Type of each element (wall, beam, door) | Dimensioning as shown on a drawing |
| Hierarchy: project, building, storey | Package-specific parameters with no IFC link |
| Basic properties: dimension, material, type | Formulas, families, parametric behaviour |
| Whatever the export settings allow | Whatever was never filled in or was unchecked |
The 2D detail drawings and the dimensioning as the draughtsman sets them out on his drawing are usually not included. IFC can technically carry 2D data, but in practice almost nobody includes their full set of drawings in the export. That means you can measure a distance in a model, but a measured dimension is not the same as a dimensioned detail drawing: the draughtsman placed that dimension line deliberately, with a context the model itself does not carry.
Why exactly that falls away
Some of what is missing falls away because it was never meant for exchange. Parameters that only exist within the source package and are not linked to an IFC property are lost on export: the package does not know which IFC field to write it to, so it writes nothing.
The intelligence of the source package also stays behind: relationships, formulas, families, parametric behaviour where one element moves with another. An IFC file is the result of that logic, not the logic itself. You get the shape that came out of it, not the recipe it was made with.
Finally, whatever the export settings switched off falls away, such as a discipline, a phase or a layer deliberately left out, along with whatever the draughtsman never filled in himself. An empty property field in the source package does not suddenly arrive filled in the IFC.
What you do with it on site, and what to check on an export
Despite those limitations, an IFC is very usable on the shop floor. You can check where something goes, confirm whether the part just delivered matches what is in the model, switch layers per discipline on or off, look up a dimension, or spot a clash before you drill or pour. A viewer such as Field-Viewer shows that model at the workstation or on a tablet on site, without letting you edit the model or write back to the source package. You do not need a licence for the CAD package: that is why a contractor can open an IFC from a subcontractor without owning that package himself.
Anyone producing or requesting an export does well to agree a few things beforehand. Agree the IFC version with whoever delivers the file. Decide which disciplines and storeys need to be in the export. Ask for the properties you need on site, not just for “an IFC”. Watch the placement and the origin point, so that two models from different sources line up. And open the export yourself once before sending it on, to see whether everything you expected has come through. Anyone drawing in Revit chooses the version and the settings themselves at that export step; in every other package the same thing happens under a different name.
A viewer shows an IFC file exactly as it arrives. It does not fix a sloppy export and does not fill in a missing property. Whatever is not there at the point of export, you will not see on screen either, however good the viewer is. Knowing that saves a lot of frustration: the problem then is not the file you open, but the agreements that came before it.