Somebody sends you an IFC and you have one question about it. Not a project’s worth of questions: just one. So I built a viewer that loads the file in the browser and has an AI sitting next to it, reading the same model. You drop the file in and you ask.
The problem
The questions are always simple ones. How many spaces are there? What’s the gross floor area on level 2? Which elements came through with no type assigned?
Answering any of them today means the same routine: open a viewer, go into the properties, filter, count, copy into a spreadsheet. Twenty minutes for something you could have asked out loud.
And the routine assumes a lot of things that often aren’t true:
- That you have the authoring tool installed, but the model may have come out of Archicad, or from a consultant who works in something else entirely
- That you know the IFC schema well enough to know where to look, which you shouldn’t have to
- That you can install software on the machine you’re sitting at
- That you have twenty minutes, and not the thirty seconds you actually have in the middle of a meeting
For one question, opening a whole BIM application is a disproportionate amount of machinery.
The solution
A web page. You drag the IFC onto it, the model appears in 3D, and there’s a chat panel next to it.
Two things happen when the file lands. The geometry gets loaded into the viewport, which is what any viewer does. And at the same time the page reads everything that isn’t geometry (the storeys, the spaces, the elements, their types, their property sets, their quantities) and builds a summary of what the model actually contains.
That summary is what the AI reads. Which brings us to the part that matters most.
The file never leaves your machine
The AI never gets the IFC. An IFC is far too big to send, and sending somebody’s model to a third party is not something you want to do casually with a file a client gave you.
What gets sent is the summary: a few kilobytes of text describing what’s in the model. Storeys and their elevations, how many spaces are on each, areas, element counts by category, how many carry a type and how many don’t.
The file itself is read locally, in the browser, and stays there. This is also why answers come back in seconds rather than minutes: the model on the other end is reading a page of text, not parsing a hundred megabytes of geometry.
How it’s built
Three pieces, and only one of them is mine.
1. The viewer
The 3D viewing and the IFC parsing come from That Open Company: @thatopen/components for the viewer and the loader, and web-ifc, their IFC parser compiled to WebAssembly, underneath. Their work is free and open source, and this tool would not exist without it. If you’re building anything with IFC in a browser, start with their engine.
The worker and the WebAssembly binary are served from the page itself rather than from a CDN, so it keeps working offline and doesn’t depend on anyone’s uptime.
2. The extractor
The part I wrote. It walks the loaded model and builds the semantic summary: storeys, spaces and their areas, elements grouped by category, type objects and, importantly, the coverage. How many elements carry a type and how many don’t. How many spaces have a name. How many quantities the exporter actually wrote.
The rule it follows is that it describes, it doesn’t judge. It counts what’s there and what’s missing. Deciding whether a gap is a problem is the AI’s job, not the extractor’s. If the list of faults were computed in JavaScript, the tool would be finding what I told it to find, which is a different and much less interesting thing.
3. The chat
The summary goes into the system prompt and gets cached between questions, so follow-ups cost about a tenth of the first one. In practice each question costs well under a cent.
There’s no backend of mine in the middle. You bring your own Anthropic API key, paste it into the panel once, and it stays in your browser’s local storage. It’s sent to Anthropic’s API and nowhere else. That also means that anyone with access to your browser can read it, so use a key scoped to this and nothing else.
And the model is still right there
It’s still a viewer. Click any element and its property tree opens: identity, every property set and quantity set the exporter wrote, and the material layers. The point of the chat is that you don’t have to go through that panel one element at a time, not that the data is hidden from you.
What it can and can’t tell you
Worth being explicit, because the failure mode of tools like this is confident nonsense.
It answers from the summary only. It’s instructed never to estimate a figure it doesn’t have, to say plainly when something isn’t in the model, and to name which measurement an area came from: an IFC space typically carries several different areas, and which one you use changes the answer.
It also keeps apart two things that are easy to confuse: a gap in the data is not a fault in the building. A wall with no quantities means the exporter didn’t write them. It does not mean the wall is wrong. Conflating those two produces a report full of alarming findings that are really just export settings.
And it is a conversation, not an audit. It doesn’t score your file, grade it, or check it against any standard. Asking it what looks inconsistent is a genuinely useful question and it answers it well, but the answer is a starting point for you to go and look, not a verdict.
Download and use
It’s free and open source under MIT. The repository has the README with the steps: clone it, npm install, npm run dev, and open the page. It’s a static page (HTML and JavaScript, no server), so npm run build gives you a folder you can host anywhere.
The OpenBIM libraries it’s built on carry their own licences, and web-ifc in particular is MPL-2.0.
If you try it on one of your own models, tell me what it got right and what it got wrong. That’s the interesting part, and it’s the part I can’t test on my own.
My BIM Tools
This viewer is part of My BIM Tools. You can find all the tools here or on my GitHub profile.