Audit a BIM Model
The quality gate before federation: audit any IFC deliverable for syntax faults, broken references, duplicate GlobalIds, orphans and missing geometry — and download the findings as a report. All in your browser, zero upload.
Runs on your device — the model is never uploaded.
Drop your IFC file here
.ifc and .ifczip · IFC2x3, IFC4, IFC4x3 — corrupted files welcome, diagnosing them is the point
No file at hand? Try a sample: ·
- to audit a 937,000-entity, 67 MB model
- 2.5 s
- page framerate held during the audit
- 144 fps
- files leave your device — the audit is fully local
- 0
Measured by this site's automated QA suite on real project models — every figure is recorded before it is published.
The quality gate before federation
A federated coordination model is only as trustworthy as the weakest discipline file inside it. That is why experienced BIM managers treat model intake as a gate, not a formality: an IFC deliverable arrives from the architect, the structural engineer or an MEP subcontractor, and before it joins the shared BIM environment, somebody has to establish that it is structurally sound. Defects hide well. An export that the authoring tool interrupted looks like a normal file until a parser hits its ragged end. Copy-paste modelling quietly stamps identical GlobalIds onto different walls. A round of hand edits leaves pointers aimed at entities that were deleted. The author never sees any of it — the person who does is whoever tries to consume the file next week.
This checker compresses that intake gate to a few seconds. Drop the deliverable, read the verdict, and either wave the model through into the federation or send it back with an itemised findings report attached. In our QA run, a 937,000-entity model weighing 67 MB was fully audited in 2.5 seconds, with the page still rendering at 144 fps while the worker did its job.
What the audit inspects
- Syntax and completeness — whether the file is genuine, well-formed STEP text from header to end marker. Truncated exports and mislabelled non-IFC files are identified together with the point where reading stopped.
- Reference integrity — every internal
#idpointer is chased down. Pointers with no target are tallied and shown with the referencing entity, so you can see which objects would lose data on import. - GlobalId uniqueness — elements sharing an identifier are grouped and listed, because coordination platforms, clash tools and CDEs all assume one id per element.
- Orphaned entities — records that nothing else in the model links to. They are inert payload; on a 2.3 MB sample house our sweep surfaced 1,245 of them, roughly 71 KB of dead weight.
- Geometry coverage — building elements that declare no shape representation. Sometimes intentional (zones, systems, placeholders), sometimes a symptom of a bad export: our stress model turned up 32,618 of these in a single pass.
How it works
- Drop the deliverable. Plain .ifc or .ifczip, from any authoring tool — and broken files are welcome on purpose, because explaining why a model refuses to open is half of what an audit is for.
- Review the findings. A single verdict — clean, clean with warnings, or defects found — backed by individual findings with severity, concrete example entities and an entity count for every class present in the model.
- Export the audit report. One self-contained HTML file holding the full results: attach it to a BCF issue, park it in the CDE next to the deliverable, forward it to the model author, or print it to PDF. No sign-up involved.
Interpreting the verdict
Findings are graded by consequence. Defects are the show-stoppers — unparseable syntax, unresolvable references — where downstream software will drop data or refuse the file entirely; the remedy is a re-export from the source model, since STEP files do not tolerate hand surgery. Warnings flag risk rather than certain failure: duplicated GlobalIds may be irrelevant for a one-time visual review yet poison a CDE's revision history, so judge them against your BIM execution plan. Notes are observations — orphaned records you can sweep out with the IFC compressor, or geometry-less elements that may be perfectly deliberate.
A habit worth institutionalising: run the gate in both directions. Authors audit their own export before it goes to the CDE, which costs seconds and avoids a bounced deliverable. Coordinators audit everything they receive, so that when the federated model misbehaves, the conversation opens with an attached report naming the defective file — not with screenshots and speculation.
When a deliverable refuses to open
Most tools give up worst exactly when you need them most: on the file that will not load anywhere. Here, a damaged model still produces a report. You learn what the file really contains, where parsing broke off, and which entity was the last intact one — enough evidence to request a clean re-export with confidence. If the model turns out healthy and you simply want to look at it, load it into the free BIM viewer; if the question is about its data rather than its shape, the properties explorer lets you search every Pset without spinning up 3D at all.
Beyond file health: IDS
Auditing against an Information Delivery Specification — required properties, classification systems, naming rules — is the logical next layer of BIM quality control, and it sits on our roadmap. If browser-based IDS checking would replace a desktop licence for you, join the waitlist inside the tool above: interest sets the priority. In the meantime, this audit catches the structural faults that would make an IDS check meaningless anyway.
Frequently asked questions
Can I audit a model before accepting a delivery?
That is the core use case. Drop the discipline export you just received from the architect, engineer or subcontractor and you get a pass/fail picture within seconds: whether the STEP structure parses cleanly, whether internal references resolve, whether GlobalIds are unique, and how many entities of each class the file contains. If the audit comes back clean, the model is safe to bring into your coordination federation; if it does not, you can return it with a concrete findings list instead of a vague complaint.
What exactly does the BIM model checker look at?
Five families of defects: STEP-level syntax problems (including truncated exports that stop mid-entity), internal references that point at express IDs which do not exist, GlobalIds that appear on more than one element, orphaned entities that no other entity links to, and building elements that declare no geometric representation. Each finding comes with plain-English context and example entities, and the whole result rolls up into a per-class inventory of the model.
Why do duplicate GlobalIds matter for coordination?
Because federation workflows treat the GlobalId as the permanent identity of an element. Clash results, BCF issues, CDE revision tracking and model diffing all rely on it being unique. If two walls carry the same id — a common side effect of copy-paste modelling or of stitching two file versions together — an issue raised against one of them can land on the other, and some checking tools refuse the file outright. The audit surfaces every collision so it can be fixed at the source.
The file opens in my viewer, so why is the audit flagging errors?
Viewers are built to be forgiving: when they hit an entity they cannot resolve, they quietly discard it and render whatever remains. That is helpful for a quick look and dangerous for a handover, because a stricter consumer — Revit, an analysis package, a rule-based checker — may reject the very same file or import it with data missing. The audit reports what forgiving software skipped over, which is exactly the information you need before signing off a deliverable.
What happens if the file is corrupt or cut off?
You still get a report. Instead of an unhandled parser crash, the tool identifies what went wrong — an export that stopped partway, a renamed non-IFC file, an archive with a misleading extension — and pinpoints where reading broke down. Since a missing tail of a STEP file cannot be reconstructed, the practical fix is almost always a fresh export or a re-transfer, and the report gives you the evidence to request one.
Is anything sent to a server during the audit?
No. A WebAssembly parser running inside your own browser tab does all of the work, in a background worker so the page never freezes. Confidential tender models and NDA-bound deliverables stay on your device from drop to report — even the downloadable HTML report is assembled locally.
How large a model can the audit handle?
There is no hard cap. The realistic ceiling is around 300 MB, set by the memory of your device rather than by us; the tool shows a friendly heads-up from 150 MB upward (80 MB combined on mobile, where browsers allow far less memory). In our own testing the audit worked through a 937,000-entity, 67 MB model in 2.5 seconds while the page held 144 fps.