Federate BIM Models
Turn separate ARC, STR and MEP exports into one federated IFC deliverable: a single IfcProject, every discipline hierarchy and property preserved, the output verified by re-parsing — with nothing uploaded anywhere.
Runs on your device — the model is never uploaded.
Model 1
Drop an IFC file here
Model 2
Drop an IFC file here
No files at hand?
Need to federate 3 or more models (architecture + structure + MEP) or merge in batch?
- IfcProject in the output — every discipline nested under it
- 1
- discipline models federated in a single pass
- 2+
- uploads — federation happens on your machine
- 0
Measured by this site's automated QA suite on real project models — every figure is recorded before it is published.
One deliverable from many disciplines
On any coordinated project, the BIM landscape splits along discipline lines: architecture in one IFC export, structure in a second, MEP in a third. Coordination platforms are happy with that arrangement — but the world outside them often is not. Clients ask for a single archive-ready model at each milestone. CDE workflows reserve exactly one slot for the coordination deliverable. Simulation and QTO packages frequently ingest only one IFC at a time, and a facilities team inheriting the asset should not receive a folder of loose fragments. Federating the disciplines — combining them into one file — answers all of these at once, without flattening anything: the output holds a single IfcProject with each source model's spatial hierarchy nested beneath it, storey by storey.
Doing this traditionally means a licensed desktop application and, often, pushing confidential models through someone else's infrastructure. Here the entire federation runs inside your browser tab: no file is transmitted anywhere, which keeps tender-stage and NDA-bound material exactly where it belongs.
How it works
- Add the discipline models. Two or more files, .ifc or .ifczip, exported from any authoring tool. Each one is indexed on arrival so you can confirm its schema, entity volume, declared units and spatial skeleton before committing to the federation.
- Clear the compatibility gate. Mixed schemas — say IFC2x3 alongside IFC4 — stop the process with an explanation rather than a corrupted result. A unit mismatch raises an amber, non-blocking warning, because geometry is never rescaled on your behalf.
- Download the verified federation. One IfcProject, all discipline hierarchies preserved, GlobalIds untouched. The result must survive a full re-parse by our viewer's engine before the download button activates — a built-in verification gate.
What federation does inside the file
Under the hood an IFC model is STEP text: numbered records (#123) pointing at
one another. Independent exports inevitably reuse the same numbers, so the federation
assigns the incoming model a fresh range and follows through by rewriting each pointer it
contains. This is pure file plumbing — BIM identity lives in GlobalIds, which pass through
byte-for-byte. Records that need no adjustment are emitted
token-identical to their source, so a diff against the
original shows exactly the changes federation requires and nothing more.
Schema rules allow only one IfcProject per file, so the first model's project becomes the root and the remaining models' site hierarchies are re-anchored beneath it. Beyond that, restraint is the design principle: owner history, representation contexts, placements and origins all remain as each discipline exported them. The resulting structure mirrors what a coordination platform assembles in memory when it stacks discipline models into one scene — so the federated file opens correctly in Revit, Solibri, BIMvision and any other schema-compliant consumer.
Coordinates, units and schemas — the three gotchas
Whether a federated model lands cleanly is decided upstream, at export time. First, a shared origin: disciplines exported against the same project base point will assemble correctly, while models that never agreed on coordinates will scatter — faithfully reproducing their source placements, since the tool moves nothing. Second, consistent units: the output inherits the lead model's unit assignment, so a unit mismatch means wrong scale, which is why the amber warning deserves a re-export rather than a shrug. Third, one schema across all files, which the tool enforces outright. After downloading, spend one minute in the viewer: expand the spatial tree, confirm each discipline's site hangs under the single project, and click a few elements to see their original properties answer back. If your BIM execution plan dictates a naming convention for the combined deliverable, just rename the download — the file's contents are independent of its name.
Federate the file — or just view together?
Not every coordination task needs a combined file. Checking a duct run against the structural frame, or presenting the merged design to a client, only requires seeing the disciplines in one scene — and the free multi-model viewer does that without producing a new file, even across mixed schemas. Reach for federation when the deliverable itself must be singular: milestone archives, single-file import pipelines, or a contractual requirement for one coordinated IFC. Once federated, two follow-ups pay off: the IFC compressor trims the duplicated definitions that combined files tend to accumulate, and the properties explorer lets you spot-check that every discipline's data crossed over intact.
Frequently asked questions
Can I federate architecture and MEP into one file?
Yes — that is precisely what this tool produces. Drop the architectural export together with the MEP export (or structural, or any mix of discipline models) and you get back one IFC file in which each discipline's site, building and storey structure survives intact under a single shared IfcProject. Ductwork stays with its systems, walls stay with their storeys, and every element keeps the GlobalId, properties and materials it had in its source file.
Does federation alter or lose any BIM data?
The operation is engineered to be lossless. Because two independent STEP files number their records from #1, the tool assigns fresh express IDs to the incoming model and rewrites each cross-reference to follow — an internal bookkeeping change that no BIM software will ever notice. Entities that need no rewriting are copied through character-for-character, identical down to the token. As a final safety net, the combined file is parsed again from scratch by the same engine that powers our viewer before the download unlocks: a verification gate, so a defective result can never reach you silently.
Can an IFC2x3 model be combined with an IFC4 model?
The tool refuses that combination on purpose. The two schemas define entities, properties and geometry differently enough that fusing them into one file would demand a full conversion of every record — a lossy transformation that has no place in a federation tool. When a schema mismatch is detected you get a clear explanation and two honest options: re-export the disciplines to a common IFC version, or skip the file merge entirely and load both models together in our multi-model viewer, which displays mixed schemas side by side without touching either file.
What happens when the disciplines use different length units?
You get an amber warning before anything is written. A single IFC file declares one unit assignment, so the federated result inherits the first model's units — and since the tool never rescales geometry, a millimetre model dropped into a metre file would land a thousand times too large. The warning does not block you (there are legitimate edge cases), but the right response is almost always to re-export the disciplines with matching units first.
Do the discipline models keep their coordinated positions?
Yes. Placements, origins, representation contexts and true north pass through untouched, so disciplines that were authored against a shared project base point will sit exactly where coordination left them. The flip side is equally true: if the source teams never agreed on an origin, the federated file will faithfully reproduce that disagreement — position problems always trace back to the exports, never to the federation step.
Are the models uploaded anywhere during federation?
No server is involved at any point. Parsing, combining and the verification re-parse all execute inside your browser via WebAssembly, on a worker thread that keeps the page responsive. Tender-stage and NDA-restricted models remain on your machine for the entire operation.
How large can the combined disciplines be?
We impose no limit of our own. Since all source models plus the result coexist in browser memory, the practical ceiling sits near 300 MB combined on a desktop machine. A heads-up appears once you pass 150 MB — and on mobile from 80 MB combined, because phone browsers grant far less memory.