The IFC file format explained: .ifc, .ifczip, .ifcxml and what's inside

An IFC file is a plain-text STEP file (ISO 10303-21, extension .ifc) that stores a building model according to the Industry Foundation Classes schema: every wall, door, duct and property set as one line of text, cross-referenced by number. The same model can also be shipped zipped (.ifczip), as XML (.ifcxml) or, experimentally, as JSON — the container changes, the data does not.

This article is about the file: what the encodings are, what the text inside looks like, how to read the header, why the files get so large and what breaks. If you want the concept first — what IFC is for and who requires it — start with What is an IFC file? and come back.

The four IFC file formats

Two things follow. First, the extension does not tell you the IFC version — an IFC2x3 file and an IFC4x3 file are both .ifc; the version is inside (next section). Second, .ifczip is not a different format, just packaging: our viewer and tools unzip it on the fly, and if a piece of software refuses it, renaming to .zip and extracting gets you the plain .ifc.

What's inside an .ifc file

Open one in a text editor (a small one — see the size section before you try this on a 200 MB federated model) and you will see two sections. This is the real header of the Duplex apartment sample that ships with our viewer, exported from Revit:

ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [CoordinationView]'),'2;1');
FILE_NAME('0001','2011-09-07T12:28:29',(''),(''),'Autodesk Revit Architecture 2011 - 1.0','20100326_1700','');
FILE_SCHEMA(('IFC2X3'));
ENDSEC;
DATA;
#1=IFCORGANIZATION($,'Autodesk Revit Architecture 2011',$,$,$);
#2=IFCAPPLICATION(#1,'2011','Autodesk Revit Architecture 2011','Revit');
#4=IFCCARTESIANPOINT((0.,0.));
#5=IFCDIRECTION((1.,0.,0.));
…
#4131=IFCWALLSTANDARDCASE('2O2Fr$t4X7Zf8NOew3FNld',#33,'Basic Wall:Interior - Partition (92mm Stud):138584',$,'Basic Wall:Interior - Partition (92mm Stud):128360',#4118,#4130,'138584');
…
ENDSEC;
END-ISO-10303-21;

The HEADER section

• FILE_DESCRIPTION — the Model View Definition the exporter targeted (here Coordination View; on IFC4 files you will see Reference View or Design Transfer View). It tells you what subset of the schema to expect.
• FILE_NAME — timestamp, author fields (often left blank, as here) and the exporting application. When a file misbehaves, this line is the first thing to check: an ArchiCAD 20 export and a Revit 2024 export fail in different ways.
• FILE_SCHEMA — the IFC version: IFC2X3, IFC4, IFC4X3_ADD2. This is the only reliable place to read it.

The DATA section

Everything after DATA; is entities: one per line, each with a number (#4131), a type in capitals (IFCWALLSTANDARDCASE) and a list of attributes in schema order. Attributes are strings in quotes, numbers, enumerations in dots (.LENGTHUNIT.), $ for "not set", * for "derived", or references to other lines (#4118). Those references are the whole design: the wall above does not contain its geometry or its properties — it points to a placement (#4118) and a shape (#4130), and elsewhere an IFCRELDEFINESBYPROPERTIES line points back at #4131 to attach its property sets. The file is a graph written out as a list.

The first attribute of every rooted element is its GlobalId — the 22-character string 2O2Fr$t4X7Zf8NOew3FNld — a compressed GUID that is meant to survive re-exports so that issue tracking, model checking and federation can follow the same wall across versions. When a tool complains about "duplicate GlobalIds", it is this attribute.

To see the same information without scrolling through raw text, drop the file into the IFC properties explorer: it lists every entity with its property sets and quantities, searchable, without rendering anything.

Why IFC files are so large — and what "normal" looks like

Text is not a compact way to store geometry. Every vertex of every face is an IFCCARTESIANPOINT line with decimal coordinates; every face is an IFCFACE plus an IFCFACEOUTERBOUND plus an IFCPOLYLOOP. In the Duplex sample above — a small two-unit house — the numbers look like this:

• 2.38 MB on disk, 38,898 entity lines
• 8,520 of them are IFCCARTESIANPOINT — 22 % of the file is coordinates
• 4,486 faces, each three lines (face, bound, loop): another third of the file
• the actual building: 57 walls, 24 windows, 14 doors, 21 slabs, 21 spaces, 4 storeys
• 1,459 property sets attached by 1,480 relationship lines

Scale that to a real project: the ArchiCAD "Institute" office model that is our medium sample is 10.9 MB and 147,712 lines; a Tekla structural export with 33,000 beams is 67 MB; a federated hospital model passes 500 MB without trying. Three habits keep this manageable:

1. Export what the receiver needs. Reference View instead of Design Transfer View for coordination, no unused property sets, no furniture and fittings in a structural exchange. Our Revit export guide covers the settings that matter.
2. Zip it for transport. The Duplex file drops from 2.38 MB to 0.48 MB as .ifczip — 80 % smaller, byte-for-byte identical once unpacked.
3. Compress it at the source when the export is bloated. Exporters frequently write the same coordinate thousands of times and leave orphaned entities behind. A lossless IFC compressor merges duplicate points and sweeps the orphans, then re-parses the result to prove nothing rooted was lost. How much you gain depends on the exporter: Tekla already deduplicates points, Revit exports typically carry a quarter of their points as duplicates, ArchiCAD exports far more.

Format vs version vs view

Three different things get called "the IFC format" and are worth keeping apart:

• Encoding — .ifc, .ifczip, .ifcxml: how the bytes are written. This article.
• Schema version — IFC2x3, IFC4, IFC4x3: which entities and attributes exist. Not backwards compatible with each other; see IFC2x3 vs IFC4 vs IFC4x3.
• Model View Definition — Coordination View 2.0, Reference View, Design Transfer View: which subset of a schema version an export promises to contain, declared in FILE_DESCRIPTION.

"Send it as IFC4" therefore under-specifies the request. A BIM execution plan that says "IFC4 Reference View, .ifczip, one file per discipline" leaves nothing to interpret.

Opening and converting an .ifc

Because the format is open, you never need the software that produced the file. The fastest look is a browser-based IFC viewer: drop the file in and it parses on your own machine — no upload, which is the sensible default for models under NDA. Desktop viewers (BIMvision, usBIM.viewer, Open IFC Viewer) and the authoring tools themselves (Revit's Link IFC, ArchiCAD's Open/Merge, Tekla's reference models) all read it too; our guide to opening IFC without Revit compares them.

For conversion, match the target to the job: IFC to glTF/GLB when you only need the geometry on the web or in a game engine; IFC to Excel when you need the data as schedules; and an import into Revit or ArchiCAD when you need an editable model — with the caveats explained in converting IFC to Revit or DWG.

When an .ifc file will not open

• It is not an IFC at all. A renamed .rvt, a PDF or a ZIP with three files inside. The first bytes should read ISO-10303-21;. A validator that sniffs the header tells you in seconds.
• It is truncated. Uploads and exports that died halfway leave a file without ENDSEC; and END-ISO-10303-21; at the end. Some viewers still show what they can; most refuse. The fix is a re-export, and the evidence is the last complete line number.
• Broken references. A line points at an entity number that does not exist, usually after a manual edit or a bad merge. Viewers vary from ignoring the element to rejecting the file.
• Character encoding. IFC escapes non-ASCII text as \X2\…\X0\ sequences; older exporters and hand edits get this wrong and property names come out as garbage. Cosmetic, but it can break naming-convention checks.

Running a delivered file through the IFC validator before you spend an afternoon on it turns each of these into a one-line finding — and into a report you can attach when you send the file back.

In short

An .ifc is readable text in STEP encoding: a short header that names the schema version, the exporter and the model view, then one entity per line, tied together by references. .ifczip is the same file zipped; .ifcxml and .ifcjson are alternative encodings you will rarely receive. Files are large because geometry is spelled out in decimals — zip for transport, export lean, compress losslessly when the exporter has been wasteful, and read the header before you blame the viewer.