IFC file health checker

What an IFC file health checker does

An IFC file health checker runs structural tests on an IFC model and lists anything that would stop other software reading it reliably: a truncated file, broken STEP records, references to records that do not exist, duplicate IDs, a missing unit assignment or more than one project. This one checks IFC2X3 and IFC4 files in your browser and downloads the findings as CSV or JSON.

Run it when an IFC will not open, opens with missing elements or behaves oddly in a coordination tool, and before you issue a model to someone else. The checks are deterministic: the same file always gives the same findings.

It is not a full validator. It does not check every rule in the IFC schema, run full IDS specifications, detect clashes or judge building code compliance. It does apply simple IDS-lite rules of the form class must carry property set, with presets such as IfcWall → Pset_WallCommon, and it can check several files in one batch. Read a clean result as no structural faults found by these checks, not as certification.

How to use the IFC file health checker

1. Choose one or up to 8 local .ifc files (50 MB each, 100 MB in total) and press Open model. To see what a clean result looks like, open the IFC4 or IFC2X3 sample.
2. If a file cannot be read at all, for example because it is truncated or uses an unsupported schema, an error explains why. Press Download diagnostic to save a text note of the failure.
3. Read the severity pills for the error, warning and info counts, then review the Selected file checks table. Each row gives the severity, the check, the records involved and a fix-it hint for that kind of finding. With several files, the Batch summary table lists counts per file; press Show to open one file's details.
4. Adjust the IDS-lite rules: each row requires a property set on every element of a class. Edit the class or set name, remove rows, press Add rule for a blank row or Add presets for the common Pset_*Common rules. Results appear as IDS rule findings at once.
5. Download the findings with Download report CSV or JSON; both include the schema, the record count, the rules and a hint per finding. For a batch, Combined CSV and Combined JSON hold the per-file summary and every finding.
6. Fix problems at the source: correct the authoring model or export settings, export again, and re-run the check on the new file.

Worked example

The included valid sample should have no duplicate IDs or dangling references. A removed referenced record produces a finding.

What's inside an IFC STEP file

An .ifc file is a text file in the STEP physical file format defined by ISO 10303-21. It starts with the line ISO-10303-21; and ends with END-ISO-10303-21;. Between them are two sections.

The HEADER section describes the file. FILE_DESCRIPTION often names the model view definition, such as ViewDefinition [CoordinationView_V2.0]. FILE_NAME records the file name, timestamp, author, organization and the software that wrote it. FILE_SCHEMA names the IFC version, such as IFC2X3 or IFC4.

The DATA section holds the model, one record per statement, for example #37=IFCWALL('0Harth0000000000000037',#5,'Sample wall A',$,$,#36,#35,$,.NOTDEFINED.);. The number after # is the express ID and IFCWALL is the entity type. The arguments are the entity's attributes in schema order: text sits in single quotes, $ means an unset value, enumerations are wrapped in dots, and #36 is a reference to another record.

Most faults this tool reports are problems with those IDs and references. Because records point to each other by number, one missing or duplicated line can break everything that depends on it.

What each IFC check means

The first three checks decide whether the file can be read as IFC2X3 or IFC4 at all; if one fails, checking stops with an error message. The rest are collected together so you see every finding in one pass.

Worked example: finding a broken reference

Press Download sample and open harth-sample.ifc in a text editor. Line #33 defines the extruded solid that gives Sample wall A its body, and line #34, the wall's shape representation, points to it. Delete the #33 line, save the file and run the checker on it.

The report lists a Dangling reference error: #34 refers to missing #33. The rest of the file is intact, but any application that tries to build wall A's geometry will fail or skip it. In a real model the fix is to export again from the authoring tool rather than patch the text, because you cannot know what the missing record contained.

Two more quick experiments show the other checks. Change FILE_SCHEMA(('IFC4')) to IFC4X3 and the file is rejected as an unsupported schema. Copy a DATA line such as #51 and paste it a second time, and the file is flagged: the STEP scan reports a Duplicate express ID, and if the parser cannot open the file at all, that is reported instead.

When you need more than a health check

This checker is quick and private, so it is a good first pass. Some questions need other tools:

• Schema conformance: buildingSMART's validation service checks files against the IFC schema and its rules in far more depth, and is the reference when a file's conformance is in dispute.
• Information requirements: IDS (Information Delivery Specification) is a buildingSMART standard for machine-readable requirements, such as every door needing a FireRating. The IDS-lite rules here cover only the simplest facet, a property set required on a class; full IDS checkers also test individual properties, values, classifications and relationships. To look at the properties yourself, use the IFC property inspector.
• Clashes and geometry: coordination software detects clashes between disciplines. This checker does not open geometry at all.
• Code compliance: no file check can certify a design against a building code. That still needs a qualified reviewer and the adopted code.

Who it is for and when to use it

Method, formulas & assumptions

Checks STEP envelope, supported schema, duplicate express IDs, duplicate root GlobalIds, missing entity references, project count, units and parser-readable records.

Parser: web-ifc 0.0.77. Library notices.

Common mistakes to avoid

• Treating a clean report as full validation. These are structural checks plus simple required-property-set rules, not schema, full IDS or code checks.
• Hand-editing IFC text to clear errors. Fixing one reference by hand can hide what the missing data should have been; export again instead.
• Ignoring the Units warning. Without a unit assignment, every dimension and quantity in the file is ambiguous.
• Assuming duplicate GlobalIds are harmless. They break issue tracking, version comparison and merges.
• Renaming a .zip or .ifcxml file to .ifc. Extract or convert it properly first.
• Checking a different export from the one you sent. Re-run the check on the exact file that was issued.

Scope & limits

Deterministic file checks only. This is not full EXPRESS/schema validation, IDS checking, geometry clash detection or building-code certification.

Frequently asked questions

Further reading

• All bim & files tools
• All free architecture & construction tools
• Harth resource library

In this category

• IFC viewer
• IFC property inspector
• IFC merge