IFC File Documentation

Summary

An IFC (Industry Foundation Classes) file is a vendor-neutral BIM model of a building or piece of infrastructure: walls, doors, beams, spaces and building services stored as semantic objects with their properties and relationships. It is an open buildingSMART standard published as ISO 16739, and the common .ifc encoding is plain-text STEP Part-21 (its MIME type is application/x-step). The file opens in a text editor but needs a BIM viewer to render the 3D model.

Technical details

FeatureValue
Full nameIndustry Foundation Classes
File extension.ifc (also .ifcxml, .ifczip)
MIME typeapplication/x-step
Format typeNeutral BIM building/infrastructure model (object model)
DeveloperbuildingSMART International
Introduced1997 (IFC 1.0)
StandardISO 16739-1 (IFC4); IFC4.3 (2024) adds infrastructure
Open standardYes — OpenBIM, royalty-free
Default encodingIFC-SPF: STEP Part-21 plain ASCII text (ISO 10303-21)
Alternate encodingsifcXML (XML), ifcZIP (ZIP-compressed SPF)
Header markerISO-10303-21; as the first line
Schema declarationFILE_SCHEMA(('IFC4')); in the HEADER section
Object rootIfcProject → IfcSite → IfcBuilding → IfcBuildingStorey
Magic numberNone (plain text; no binary signature)
Used forDesign coordination, clash detection, quantity take-off, facility management
Related extensions.ifczip, .ifcxml, .step, .dwg, .rvt
Specificationtechnical.buildingsmart.org/standards/ifc/
Structure at a glance

The default .ifc encoding (IFC-SPF) is a plain-text STEP Part-21 file, so it has no binary signature. It always begins with the literal line ISO-10303-21; and a HEADER; section whose FILE_SCHEMA names the IFC version, for example FILE_SCHEMA(('IFC4'));. The model itself lives in a DATA; section as numbered instances such as #42=IFCWALLSTANDARDCASE(...), each line one object. The file ends with ENDSEC; and END-ISO-10303-21;. The .ifczip variant is this same text compressed in a ZIP, so it instead begins with the ZIP header 50 4B 03 04 (PK).

What is an IFC file?

IFC stands for Industry Foundation Classes, the open international standard for exchanging Building Information Modeling (BIM) data. It was first released as IFC 1.0 in 1997 by the organisation now called buildingSMART International, and is published as the ISO 16739 standard. An IFC file is a complete digital model of a building or, since IFC4.3 (2024), a piece of infrastructure such as a road, bridge or rail line. Its reason to exist is interoperability: every BIM authoring tool (Autodesk Revit, Graphisoft Archicad, Tekla, Nemetschek Allplan) has its own native format, and IFC is the neutral OpenBIM format they can all export and import so that an architect, a structural engineer and a contractor on different software can share one coordinated model.

An IFC file is far more than geometry. It is an object model. It describes each building element as a semantic object, such as IfcWall, IfcDoor, IfcBeam, IfcSpace or IfcPipeSegment, together with the object’s properties (material, fire rating, dimensions, classification code), its relationships to other objects (a door hosted in a wall, a space bounded by walls), the spatial hierarchy that contains it, and the geometry needed to render it. That semantic richness is why IFC supports clash detection, quantity take-off and code checking, not only visualization.

The IFC-SPF encoding: a STEP Part-21 text file

The most common encoding of IFC, and the one the plain .ifc extension refers to, is IFC-SPF: the STEP Physical File format defined by ISO 10303-21, the same “Part 21” text encoding used by mechanical STEP files. It is plain ASCII, so the file opens in any text editor, though it is meaningless to a human without a viewer to interpret the objects. Every conformant file has the same skeleton.

ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [CoordinationView]'),'2;1');
FILE_NAME('project.ifc','2024-05-01T10:00:00',('Architect'),('Firm'),
          'IfcOpenShell','Revit','');
FILE_SCHEMA(('IFC4'));
ENDSEC;
DATA;
#1= IFCPROJECT('0YvhhKh...',#2,'Project',$,$,$,$,(#20),#7);
#42= IFCWALLSTANDARDCASE('3vB2Yo...',#2,'Basic Wall',$,$,#55,#60,$);
...
ENDSEC;
END-ISO-10303-21;

The first line is the literal marker ISO-10303-21;. The HEADER section records who authored the file and, critically, the FILE_SCHEMA line that names the IFC version the file conforms to (IFC4, IFC2X3, and so on). A reader must know the schema to interpret the entities correctly, because the meaning of every object type is defined by that schema’s EXPRESS specification. The DATA section is the model itself.

Entity instances: the #-numbered lines

Inside the DATA section, every object is one instance line of the form #N= ENTITYTYPE(attr1, attr2, ...);. The #N is a unique instance identifier within the file, and the attributes are positional: their order and type are fixed by the entity’s definition in the schema. An attribute is either a literal value (a quoted string, a number, an enumeration written as .T. or a keyword), a reference to another instance written as #N, an inline list in parentheses, or the unset marker $.

Reference-by-number is what turns a flat list of lines into a graph. A wall instance does not embed its geometry or its owner; it points at other #N instances that hold them. This is why an IFC file cannot be read line by line in isolation: resolving one wall means following its references to a placement, a shape representation, an owner history and a set of properties, each of which is its own numbered instance elsewhere in the file. The first attribute of most rooted objects is a 22-character Globally Unique Identifier (GUID), a compressed base-64 encoding of a 128-bit UUID that lets the same object be tracked across exports and revisions.

The spatial hierarchy: project, site, building, storey, space

Every IFC model is organised under a strict containment tree so that tools know where each element belongs. The root is a single IfcProject, which owns the units and the world coordinate system. Below it the standard chain is IfcSite, IfcBuilding, IfcBuildingStorey and IfcSpace.

IfcProject
  IfcSite
    IfcBuilding
      IfcBuildingStorey  (a floor level)
        IfcSpace         (a room)
        IfcWall, IfcSlab, IfcColumn, IfcDoor ...  (elements on this storey)

This tree is not implied by nesting in the text; it is expressed explicitly through relationship objects. An IfcRelAggregates instance links a parent to its children (project to site, site to building, building to storey), and an IfcRelContainedInSpatialStructure instance links a storey to the physical elements placed on it. A reader builds the model tree by resolving these relationship instances, not by reading the file top to bottom.

Property sets and objectified relationships

IFC deliberately keeps an element’s intrinsic data separate from the properties attached to it. A wall object carries only its core attributes; everything else (its thermal transmittance, its fire rating, its cost code) lives in a property set, an IfcPropertySet containing named IfcPropertySingleValue entries. A property set is bound to one or more elements through an IfcRelDefinesByProperties relationship, so the same set can describe many walls at once. buildingSMART defines standard sets (names prefixed Pset_, such as Pset_WallCommon) so that different tools agree on what a property means.

Relationships in IFC are themselves objects, a pattern called objectified relationships. Rather than storing “this door is in that wall” as a field on the door, the model creates an IfcRelVoidsElement and an IfcRelFillsElement instance to describe the opening and the door that fills it. Making relationships first-class objects lets a relationship carry its own attributes and lets many-to-many links be expressed cleanly, at the cost of more instances to resolve.

Geometry: extrusions, B-rep and placement

An element’s shape is held in an IfcProductDefinitionShape that groups one or more IfcShapeRepresentation objects, each tagged with how it should be interpreted (a bounding box, a curve, a swept solid, a faceted B-rep, a tessellated mesh). The most compact and common representation is the swept solid: a 2D profile plus an extrusion direction and depth, encoded as IfcExtrudedAreaSolid, which lets a straight wall be described by its cross-section and length rather than by every face. More complex shapes use IfcFacetedBrep (an explicit list of faces and vertices) or, in IFC4, a tessellated mesh for imported or organic geometry.

Placement is layered so that geometry can be defined once and positioned many times. Each element has an IfcLocalPlacement that is relative to its container’s placement, so a storey’s coordinate system is relative to the building’s, which is relative to the site’s. A viewer computes an element’s world position by walking that chain of relative placements up to the project origin. This is also why moving a storey correctly moves every element on it: they are all defined relative to the storey’s placement, not in absolute coordinates.

ifcXML and ifcZIP: the other encodings

The same model can be serialised three ways. The default .ifc is the STEP text form described above. The .ifcxml variant expresses the identical object graph as XML, which is more verbose but easier to process with generic XML tooling. The .ifczip variant is simply an IFC-SPF (or ifcXML) file compressed inside a ZIP archive, which typically cuts the size by an order of magnitude because the text is highly repetitive; it begins with the ZIP signature 50 4B 03 04 rather than ISO-10303-21;. All three carry the same information and open in the same viewers, so the choice is about file size and tooling, not about model content.

Frequently asked questions

Why does my IFC file open as text in Notepad?

Because the standard .ifc encoding is a STEP Part-21 text file. Opening it shows the header line ISO-10303-21; and thousands of #N= IFC... instance lines. That is the real file; to see the 3D building you need an IFC-aware BIM viewer that resolves those instances into geometry.

If IFC uses the same encoding as STEP, are they interchangeable?

They share the ISO 10303-21 text syntax but use completely different schemas. A mechanical STEP file describes machined parts as B-rep solids; an IFC file describes building objects with construction semantics. A tool must know which schema a file uses (from its FILE_SCHEMA line) to interpret it, so the two are not directly interchangeable despite looking similar.

References