IFC merge

What an IFC merge tool does

An IFC merge tool combines several IFC models into a single IFC file with one project. This one takes 2 to 8 models that share a schema, units, representation context and coordinate system, renumbers their records so they do not collide, joins their spatial structures under the first file's project, and downloads merged.ifc.

It is deliberately conservative. A preflight report lists each file's schema, units, contexts, storeys and any GlobalId clashes before anything is combined, and incompatible inputs are rejected with a specific reason rather than repaired. It never rescales geometry; it only moves a model when you type an offset or rotation for it, and it asks you to confirm that the models line up before it runs. Same-named storeys can be reconciled so the merged file has one Ground floor rather than one per source.

Everything happens in your browser. Each input is checked with web-ifc, the merged output is parsed again and checked for broken references, and nothing is uploaded.

How to use the IFC merge

1. Choose 2 to 8 .ifc files (50 MB each, 100 MB in total), all IFC2X3 or all IFC4. To see the process first, press Try compatible sample pair.
2. Tick I have verified that these files share the same coordinate frame and intended placement. Leave Reconcile storeys by name ticked to move later files' elements onto the first file's same-named storeys, or untick it to keep every storey separate.
3. If a model needs shifting, enter Offset X, Y, Z in that file's project length unit and a Rotation in degrees about Z for each file after the first. The offset is applied by re-parenting the file's root placements; geometry itself is untouched.
4. Press Run preflight. The report lists every file's schema, record count, projects, units, contexts and storeys, plus clashing GlobalIds and any blocking issue. Fix the inputs if it is blocked; otherwise press Merge now.
5. Download merged.ifc. The status line reports how many models were merged and how many root entities and storeys the result contains; the merged file is parsed again before it is offered.
6. Open the result in the IFC viewer to confirm alignment, then check it in your own coordination workflow before relying on it.

Worked example

Merge the bundled sample and companion model to place three walls in one project.

Merging vs federating IFC models

Most coordination workflows never merge IFC files. They federate them: each discipline's model stays a separate file, and a coordination tool loads them together in one view. Federation keeps ownership clear, because the structural engineer can re-issue their model without touching anyone else's.

A merged file is useful when a single file is required: a platform or client that accepts one IFC per upload, an archive copy of an issued set, a simple hand-off, or a tool that only opens one model at a time. The trade-off is that a merged file is a snapshot. When one discipline re-issues, the merge has to be run again.

What makes IFC models compatible for merging?

The tool checks every input against the rules below and stops with a message if any fails. Nothing is converted to make files fit.

Why IFC files in feet and inches are rejected

IFC stores lengths as plain numbers and declares the unit once, in the project's IfcUnitAssignment. Metric exports use IfcSIUnit entries such as METRE or MILLIMETRE. Models set up in feet and inches are usually exported with an IfcConversionBasedUnit, a foot defined in terms of the metre. This tool only merges models whose units are all SI, and all the same.

The rule is strict because a unit mismatch is invisible until it is too late. A coordinate of 4000 means 4 m in a millimetre model and 4 km in a metre model, so merging the two would place elements 1,000 times too far away. If your team works in imperial, export every model to be merged with the same metric units and the same export settings. Use the construction unit converter to check dimensions between systems.

Getting models to line up before you merge

The merge copies each model's placements exactly unless you give it an offset or rotation. It cannot know where models should sit relative to each other, which is why you are asked to confirm alignment; when one file is simply shifted or turned about Z, type the offset in that file's project length unit and the rotation in degrees, and the tool re-parents the file's root placements under a new IfcLocalPlacement rather than editing coordinates. If the architect exported relative to one origin and the engineer relative to another, the merged walls and columns will simply be in the wrong places.

Agree a shared origin before anyone exports. In Revit the IFC export setup lets you choose the coordinate base, such as shared coordinates or the project base point; in Archicad, the IFC translator controls whether the project origin or survey point is used. Whatever you choose, every discipline must export the same way.

Files with georeferencing (IfcMapConversion or a projected CRS, which IFC4 exporters can write) are rejected rather than merged, because two map conversions cannot be combined without transforming coordinates. Export without georeferencing for the merge, or keep federating the models.

Worked example: press Try compatible sample pair. The IFC4 sample (48 records, walls A and B) and a companion file (47 records, one wall placed 6 m, or 19 ft 8¼ in, along the x axis) share a schema, metre units and an identical context. The companion's IfcProject is dropped and its site is attached to the first project, the two project aggregation relationships become one, the companion's Ground floor is reconciled onto the first file's Ground floor, and every record is renumbered. The result is a 91-record merged.ifc with two sites, one storey and three walls under a single project (93 records with two storeys if reconciliation is off).

Who it is for and when to use it

Method, formulas & assumptions

A conservative merger requires the same schema, matching SI project units, identical model contexts and a shared coordinate frame. It remaps express IDs, joins project aggregation and rejects conflicting GlobalIds.

Parser: web-ifc 0.0.77. Library notices.

Common mistakes to avoid

• Ticking the alignment box without checking. Open each model and confirm a shared grid intersection or corner sits at the same coordinates.
• Merging a file with a copy or re-export of itself. The shared GlobalIds are rejected as duplicates.
• Exporting disciplines with different settings. Millimetres in one file and metres in another, or a different precision, is enough to be rejected.
• Treating the merged file as the new master model. When one discipline re-issues, merge again from the new inputs.
• Skipping the IFC file health checker. Files with structural errors are rejected, so fix them first.
• Expecting a merge to reconcile georeferenced models. Files with map conversions are outside the supported subset.

Scope & limits

IFC2X3/IFC4 only, one project per file, SI units, matching contexts, no map conversion or external references. You must confirm aligned coordinates. Incompatible inputs are rejected; the tool does not transform or repair models.

Frequently asked questions

Further reading

• All bim & files tools
• All free architecture & construction tools
• Harth resource library

In this category

• IFC viewer
• IFC property inspector
• IFC file health checker