Is my IFC file uploaded anywhere?

No. Files are parsed entirely in your browser via web-ifc, a WebAssembly build of the open-source IFC parser. Nothing leaves your machine. The app works completely offline once loaded.

Can I use it with confidential models under NDA?

Yes. Because all processing happens in your browser and no data is ever transmitted to any server, you can safely use it with confidential project models under NDA. There is no service agreement to review with your client — no data changes hands.

Can I share the validation results with my team or client?

Yes. After running validation, click Share Report to copy a link that encodes the full Health Score and issue list directly in the URL — no file upload, no server, no account required. You can also export results as JSON, CSV, or a Validation Certificate. The IFC file itself never leaves your browser.

Yes, fully. IFC Viewer Online works on any modern browser — Chrome, Edge, Firefox, and Safari on both Mac and Windows. No plugin, no installation, no operating system restriction.

What happens if my IFC file is very large?

The app handles files up to 2 GB. Performance depends on your device — files under 200 MB load well on most modern hardware. Once parsed, geometry is cached in OPFS so every subsequent load of the same file is instant, even offline.

How does the validation work?

The validator runs 44 built-in rules in a background Web Worker so the UI stays responsive. Rules cover GUID duplicates, spatial hierarchy, orphan elements, naming conventions, missing type assignments, ISO 19650 property sets, LOD completeness, clash detection, proxy overuse, coordinate offset, storey-elevation integrity, unit consistency, and more. You can also run a buildingSMART IDS specification against the model. Every model receives a Health Score from 0 to 100. Results stream in as each rule completes.

Can I fix errors and re-export a corrected IFC?

Yes. All edits (GUID fixes, renames, property value changes) are held as non-destructive diffs with full undo/redo. Clicking Export IFC applies all diffs to the original binary in a Web Worker and downloads the corrected file — no server involved.

What IFC versions are supported?

IFC2x3, IFC4, IFC4x1, and IFC4x3. The viewer uses the open-source web-ifc parser — the same engine used by most modern BIM tools and @thatopen/components. Outdated schemas are automatically flagged by the validator.

What measurement tools are available?

You can measure lengths between any two points, areas of surfaces, volumes of enclosed elements, and individual edge lengths — all directly in the 3D viewport. Measurements persist as labelled annotations and can be exported alongside your model.

Can I load multiple IFC files at once?

Yes. Load as many IFC files as your device memory allows. Each model has independent visibility, transforms, validation, quantity takeoff, and export. Use the Scene panel to manage, reorder, or remove models at any time.

Does it work offline?

Yes, once the page is loaded. The WebAssembly parser and WebGL renderer run entirely in the browser. Parsed geometry is cached in OPFS so repeat loads are instant even without a network connection.

What are the file size limits?

There is no enforced limit — performance depends on your device. Files up to ~200 MB typically load well on modern hardware. The OPFS geometry cache means you only pay the parse cost once per file.

Is it free? Can I use it for commercial projects?

Yes, completely free. The source code is MIT-licensed. You can use the live app or fork the repository for your own projects, including commercial ones.

Back to the BIM & IFC blog

Tool Guides · 2026-06-03 · 9 min

How to View IFC in the Browser with three.js, web-ifc & Fragments

Loading an IFC into a three.js scene sounds simple until the first 200 MB model freezes the tab for two minutes. The trick the libraries teach is: don't parse IFC at runtime. Here's how web-ifc, Fragments, and a convert-once pipeline actually fit together.

How to View IFC in the Browser with three.js, web-ifc & Fragments — IFC Viewer Online article cover

Rendering IFC on the web is a solved problem — but only if you follow the pattern the libraries are built around. Developers who try the naive approach (load the .ifc, parse it, build meshes, every time) hit a wall on the first real model: the tab freezes for a minute or more while WebAssembly chews through the file. The fix isn't a faster parser; it's parsing once and never again.

The Stack

web-ifc

The WebAssembly core (from That Open) that reads and writes IFC at near-native speed in the browser or Node. The foundation everything else sits on.

Fragments

That Open's optimized geometry format. You convert IFC → Fragments once; loading the .frag afterward is dramatically faster than re-parsing the IFC.

three.js

The WebGL renderer that draws the scene. Fragments produce three.js-compatible geometry you add to a scene, camera, and controls like any other meshes.

The Naive Approach (and Why It Hurts)

import * as WebIFC from "web-ifc";

const api = new WebIFC.IfcAPI();
await api.Init();

// Parsing the raw IFC at runtime — fine for tiny files, painful for real ones
const data = new Uint8Array(await file.arrayBuffer());
const modelID = api.OpenModel(data);
// ...extract geometry, build meshes... (slow, blocks the main thread)

The Production Pattern: Convert Once, Load Many

Convert the IFC to Fragments a single time (on upload, in a worker, or in a build step).
Persist the .frag output — in cache, OPFS, or object storage.
On every load after that, fetch the Fragments and render — no IFC parsing involved.
Run the heavy work in a Web Worker so the main thread stays responsive.

import * as OBC from "@thatopen/components";

const components = new OBC.Components();
const fragments = components.get(OBC.FragmentsManager);
const ifcLoader = components.get(OBC.IfcLoader);
await ifcLoader.setup();

// First time only: IFC → Fragments
const model = await ifcLoader.load(ifcBytes);

// Serialize once, reuse forever
const frag = fragments.export(model.group);
await saveToCache(frag);          // OPFS / IndexedDB / server

// Subsequent loads: skip IFC entirely
const cached = await loadFromCache();
fragments.load(cached);            // fast

Common Pitfalls

"memory access out of bounds": the web-ifc WASM ran out of memory on a big file — convert in a worker, increase available memory, or process in chunks.
Geometry far from the origin jitters: models authored at true geographic coordinates lose floating-point precision; rebase to a local origin. (See 'IFC Coordinates Are Wrong'.)
No server-side rendering: web-ifc runs in the browser/Node, not as a no-JS SSR step — plan for client-side or a build-time conversion, not request-time SSR.
Loading optimization: tile and cull large models so you only draw what's near the camera. (See 'Why Large IFC Files Crash Your Browser'.)

Or Don't Build It

This is exactly the pipeline this viewer runs: web-ifc for parsing, a Fragments-style convert-once step, OPFS caching so repeat loads are ~10× faster, and validation on top. If your goal is to view and check IFCs rather than to build a viewer, you can skip the engineering and just open the file.

See the pipeline in action

A production-size IFC4 model loaded with exactly this convert-once, cached pipeline. Open it, then reload — the second load is near-instant.

IFC4 · 14 MB

Open the interactive IFC viewer

Embed It in Your Own Page

If you host your IFC somewhere public (a CORS-enabled bucket, a raw repo link, or your CDE), you can drop this exact viewer into a blog post, docs page, or CDE panel with a single iframe — no build step. Paste a URL below, tweak the layout, and copy the snippet. The model is fetched in the visitor's browser, so nothing is uploaded to us.

Build your IFC embed

Paste a public IFC URL, choose a layout, and copy the iframe. Live preview updates as you go.

Open IFC Viewer

How to View IFC in the Browser with three.js, web-ifc & Fragments