Back to the BIM & IFC blog
Tools & comparisons · 2026-10-02 · 11 min
What's Inside an IFC File? The Format Explained With Diagrams
An .ifc file is plain text you can open in a code editor — and once you know how to read it, half of the mysteries of IFC disappear. The header, the numbered instances, the GlobalId, the relationships that carry properties: here is the format, drawn out.
What's Inside an IFC File? The Format Explained With Diagrams — IFC Viewer Online article cover
Most people only ever see an IFC file through a viewer. That is a shame, because an .ifc file is plain text, and ten minutes spent reading one explains things that otherwise stay mysterious: why GUIDs matter, why a property can be "missing" when you can see it, why files get so large, why one wrong setting in an export breaks everything downstream.
This guide opens the file and draws what is inside.
An IFC file in the STEP format (ISO 10303-21): a header that names the schema, then one numbered instance per line.
Key takeaways
- An IFC file is a list of numbered instances. The numbers are local to the file and change on every export.
- The GlobalId — the 22-character string inside each instance — is the identity that is meant to last.
- Almost everything interesting, including properties and spatial containment, is attached through relationship entities rather than stored on the element.
The header: which schema, which view
The file opens with ISO-10303-21; and a short HEADER section. Three lines in it matter:
- FILE_DESCRIPTION names the model view definition — Coordination View, Reference View, Design Transfer View — which defines the subset of IFC the exporter intended to use.
- FILE_NAME records the file name, timestamp, author and the authoring application.
- FILE_SCHEMA names the schema: IFC2X3, IFC4 or IFC4X3. Every line below it is read against that schema; the same entity can have different attributes in different versions.
Choosing between schema versions is its own topic: IFC2x3 vs IFC4.
The data: one instance per line
After DATA; every line has the same shape: a number, an entity name, and a list of attributes in the order the schema defines them.
#245= IFCWALL('1kTvXnbbzCWw8lcMd1dR4o',#2,'Basic Wall:Ext 300',$,$,#210,#240,$,.STANDARD.);
| Token | Meaning |
|---|
| #245 | Instance number (express ID) — local to this file |
| '1kTvXnbbz…' | GlobalId — a 22-character compressed GUID |
| #2 | Reference to another instance (here, the owner history) |
| $ | Attribute not set |
| .STANDARD. | An enumeration value (the predefined type) |
| #210, #240 | Placement and geometric representation, defined on other lines |
When the GlobalId itself changes on every export, every downstream process breaks at once. The cause and the fix per authoring tool are in why IFC GUIDs change on every export.
Entities inherit from each other
IFC is an object model. An IfcWall is an IfcBuiltElement, which is an IfcElement, an IfcProduct, an IfcObject, and ultimately an IfcRoot — and it carries the attributes of every one of them. That is why every wall, door and space has a GlobalId and a Name: they come from IfcRoot.
Every entity inherits the attributes of its supertypes. A check written for IfcElement applies to every wall, door and column below it.
Names change between versions: what IFC4.3 calls IfcBuiltElement was IfcBuildingElement in IFC2x3 and IFC4. A tool that hard-codes one name misses the other — which is one reason the same model can pass a check in one tool and fail it in another.
Relationships are entities too
The design decision that makes IFC hard to read at first is also what makes it powerful: relationships are objects in their own right. A wall does not have a list of its properties. Instead, an IfcRelDefinesByProperties instance points at the wall and at a property set. Spatial containment, materials, types, openings and groups all work the same way.
Properties live in property sets, attached to the element or to its type. A property set on the type applies to every occurrence.
This is the root of the most common false alarm in IFC quality checks: a property that is defined on the type looks missing to a tool that only reads the occurrence. IFC properties missing after export covers the real causes; reading property sets in Python shows how to follow these relationships in code.
Why IFC files get so large
- Geometry dominates. A triangulated façade or a detailed MEP fitting can take thousands of lines; extrusions and mapped (instanced) geometry are far smaller.
- Repeated data is repeated. Exporters that do not share property sets or representations write the same lines once per element.
- Nothing is compressed in plain STEP. ifcZIP typically shrinks a file several times over, and is a sensible delivery format when the recipient's tools accept it.
The safe ways to make files smaller are in how to reduce IFC file size. And when a file is large enough to crash a browser, see large IFC files and browser crashes.
Reading a file yourself
- Open it in a text editor Any editor that copes with large files. Look at the header first: schema and model view tell you what to expect.
- Search for the entity you care about IFCWALL(, IFCSPACE(, IFCBUILDINGSTOREY(. The count alone is a quick sanity check.
- Follow one element's references From a wall, search for its # number to find the relationships that point at it — containment, properties, type.
- Then switch to a viewer The same information, navigable: the spatial tree, the property panel, and validation that checks these relationships for you.
How the elements are organised into storeys and spaces is the subject of the IFC spatial structure explained.
What's Inside an IFC File? The Format Explained With Diagrams