My IFC file won't open in Revit — what should I check first?

Before touching Revit at all, load the same file into a neutral browser viewer. If it renders there, the file is fine and the fault sits in Revit's import path — usually a schema Revit's IFC importer handles poorly, a mapping quirk, or memory. If the browser viewer also fails, run the file through an IFC audit: a truncated or internally broken export will fail everywhere, and the audit names the defect so you can request a precise re-export instead of guessing.

How can I tell if an IFC file is corrupt?

Symptoms are suggestive — a size far smaller than expected, a load that dies at the same point every time, failures across several unrelated tools — but only a structural audit is conclusive. The browser-based IFC validator on this site parses the whole file and reports whether the STEP text is complete, where reading broke off if it is not, and which internal references or identifiers are damaged. A corrupt file produces a diagnosis, not a crash.

Can a corrupted IFC file be repaired?

Honestly: not reliably, and no tool we know of changes that. When the tail of a STEP file is missing, the data it held is gone — nothing can reconstruct entities that were never written. What tooling can do is tell you exactly what is broken and where, which turns "the model doesn't work" into a specific re-export request the author can act on in minutes. Treat repair claims with suspicion; treat a clean re-export as the fix.

Is a confidential model safe in a browser viewer?

In this one, yes, because there is no upload step to worry about. The viewer and every tool on this site parse the IFC with WebAssembly inside your own browser tab; the file stays on your device from drop to result, no account required. That is a property of the architecture, not a policy promise — there is simply no server on the receiving end. Cloud viewers that ingest your file to render it are a different category; read their terms before feeding them tender-stage work.

Which IFC schema should I ask teams to deliver?

Whatever the weakest consumer on your project can actually read — which is why the BIM execution plan should name it explicitly. IFC2x3 remains the safest common ground and the default currency of exchange; IFC4 fixes real limitations and is broadly supported by current tools; IFC4x3 matters when the project involves infrastructure. Mixing schemas across disciplines is survivable for viewing but painful for automated checking, so pick one and hold everyone to it.

BIM model not opening: the four causes and how to tell them apart

Updated August 3, 2026 · BIMViewer team

A BIM model refusing to open, diagnosed in a browser-based IFC viewer

Sooner or later every project hits it: the deliverable is due, a discipline model lands in your inbox, and it will not open. The authoring tool crashes mid-import, or hangs at a progress bar forever, or throws a dialog that explains nothing. The instinct is to restart, update, reinstall, retry — and each lap of that loop costs half an hour and proves nothing, because the loop never asks the only question that matters: is the problem the file, or the software?

The good news is that failed opens are not mysterious. Nearly all of them trace back to four causes, each leaving different fingerprints, and each identifiable from a browser tab — no license seat, no reinstall, and no upload, since every tool used below parses the file locally on your machine. Here are the causes, then the triage order that separates them.

Why a BIM model refuses to open

"BIM problems" is a broad complaint, but opening failures cluster tightly: the schema doesn't match what the consumer expects, the file is damaged, the exporter wrote something the importer misreads, or the model is simply larger than the machine. Telling them apart is the whole job — a fresh export cures truncation but does nothing for a memory ceiling, and shrinking a file is wasted effort when the real fault is a schema mismatch.

1. Schema and version mismatch

IFC exists in generations — IFC2x3, IFC4, IFC4x3 — and not every consumer reads every one of them. Hand an IFC4x3 infrastructure model to a pipeline that stops at IFC2x3 and it may refuse the file outright, or worse, import a hollow shell with geometry or properties silently dropped. Native formats fail harder still: a Revit file saved by a newer release is a closed door to any older one. The tell for this cause is asymmetry — the file opens fine in some tools and not in others.

2. Corruption and truncation

An IFC is one long STEP text stream, and anything that interrupts its writing or transfer — an export that died, a cloud sync that stopped early, a full disk, a flaky USB stick — leaves a file that ends mid-entity. The cruel detail is that a truncated model looks completely normal from the outside: right extension, plausible size, correct icon. Only a parser reaching the ragged end finds out, which is why this cause fails everywhere, not just in one product.

3. Exporter quirks

Between "valid" and "broken" sits a wide band of files that are technically legal IFC but awkwardly written. Every authoring platform maps its internal objects to IFC in its own way, and the results — unusual geometry representations, properties filed in unexpected sets, unit oddities, boolean operations one importer resolves and another chokes on — can stall a specific consumer while every other tool shrugs and renders the model. This cause wears the same asymmetric fingerprint as a schema mismatch, but the fix lives in the exporter's settings rather than in the schema choice.

4. Size against memory

Some models never get to fail on content — they exhaust the machine first. Parsing an IFC inflates it considerably in RAM, so a heavy multi-discipline export can take down a desktop import with no error message beyond a freeze or a crash. Browser tools live under the same physics: on this site the practical ceiling is around 300 MB depending on device memory, with a warning shown from 150 MB (80 MB combined on mobile). A model that opens on the workstation with 64 GB and dies on the laptop is telling you exactly what its problem is.

The triage order: five moves, most of them in a browser

Triage flowchart for a BIM model that won't open: neutral viewer, file audit, schema check, slimming, re-export — Work top to bottom: each step either ends the problem or eliminates a suspect.

Step 1 — Reproduce it in a neutral viewer

Before anything else, drop the file into the browser viewer. This single move splits the universe of causes in half. If the model renders, the file is fundamentally sound and your desktop software owns the problem — jump to steps 3 and 5. If a viewer with a different parser, different vendor and different memory profile also fails, the file itself is now the prime suspect. Either way you learned more in one minute than a reinstall teaches in an afternoon.

Step 2 — Audit the file itself

Suspicion isn't diagnosis. Run the file through the IFC validator, which parses the whole STEP stream and reports on its structural health: exports cut off mid-entity, internal references pointing at records that don't exist, GlobalIds shared by multiple elements, orphaned entities, building elements with no geometry. Crucially, a damaged file doesn't produce an error here — it produces a diagnosis, including where reading broke down. That report is the difference between telling the author "your model is broken" and telling them what to fix.

IFC validator findings for a defective model, graded by severity — An audit turns a refusing file into a findings list you can forward to the model author.

Step 3 — Read the schema badge

When the viewer opens the model, its status bar names the schema — IFC2X3, IFC4 or IFC4X3 — alongside the element count, file size and load time. Compare that badge against what your failing software actually supports (its documentation will say; its error dialog probably didn't). A surprising number of "corrupt file" tickets end here, as an IFC4 export sent to a tool configured for IFC2x3, fixed by one changed dropdown at export time.

Viewer status bar showing the IFC4 schema badge with element count, size and load time — The status bar answers the schema question the error dialog wouldn't.

Step 4 — Slim it, or skip the 3D entirely

If the evidence points at size, shrink the payload before shrinking your ambitions. The IFC compressor removes what no design tool will miss — repeated coordinate points, records nothing references — losslessly, and re-parses its own output before letting you download it. And question whether you need the geometry at all: when the deadline actually calls for a quantity, a property or a schedule, the properties explorer or an Excel export reads the data straight out of the file without ever standing up a 3D scene — a far lighter operation than rendering, and often the whole task in disguise.

Step 5 — Fix it at the source

Everything above is triage; the durable cure for a bad file is a better export. Send the author your audit findings and the target schema, and have them re-export with settings that match the project's exchange agreement — for Revit-based teams, our guide to exporting Revit to IFC walks through the settings that matter. This is also where splitting belongs: re-exporting per discipline or per storey turns one monolith into files any machine can open, isolates which part carries the fault, and — since the viewer federates multiple IFCs into one scene — costs you nothing in the coordination picture.

The time argument: diagnose before you reinstall

There's a quieter reason to run this triage in a browser, and it's the one that changes weeks rather than evenings. The desktop debugging loop — reopen, wait, crash, tweak, wait again — bills you several minutes per lap and can eat a morning without producing a single fact. A browser check of the same file costs seconds, occupies no license seat, and ends with an answer instead of a hope. The people who seem calm the night before a delivery are not lucky; they simply stopped paying the loop tax.

The same shift applies to communicating what you find. Instead of emailing screenshots of error dialogs, open the model, cut into the offending zone with a section plane, isolate the elements in question and save a PNG snapshot — a picture of the actual problem, taken in a tool the recipient can open the model in themselves, for free, without installing anything.

Prevention: make refusing files rare

Three habits keep this article's problems theoretical. Agree exports in the BEP: the BIM execution plan should name the schema, the export settings and the delivery cadence per discipline, because most interoperability pain is two teams making different reasonable assumptions. Audit on arrival: run every incoming deliverable through the validator before it enters the federation — a broken file caught at intake costs an email; caught during coordination it costs a meeting. Keep a neutral viewer in every toolkit: most people on a project consume models rather than author them, and giving every one of them a free local viewer means the file-versus-software question gets answered wherever it appears, not queued behind whoever holds a license.

Models will still occasionally refuse to open — exports get interrupted and machines run out of memory in every well-run project. The difference discipline makes is what happens next: ten minutes of browser triage and a findings report, instead of a 2 AM staring contest with a progress bar.