Back to the BIM & IFC blog
Validation · 2026-06-03 · 8 min
Why IFC GUIDs Change on Every Export (and How to Keep Them Stable)
You re-export the same model, send it to your coordinator, and every BCF comment, clash issue, and FM tag is suddenly pointing at the wrong element — or nothing at all. The cause: your IFC GlobalIds were regenerated. Here's why it happens and how to lock them down.
Why IFC GUIDs Change on Every Export (and How to Keep Them Stable) — IFC Viewer Online article cover
There are two completely different GUID problems in IFC, and they get confused constantly. The first is duplicate GUIDs — two elements sharing one GlobalId in a single file. The second, covered here, is GUID instability: the same element getting a different GlobalId every time you re-export the model. Both break coordination, but the second is sneakier, because each individual file looks perfectly valid.
If you coordinate clashes, run BCF workflows, or hand a model to facilities management, stable GlobalIds are not optional. They are the only thing that lets a tool say 'this wall in revision 4 is the same wall as in revision 2'. When they drift, every reference that pointed at the old ID silently dangles.
- 22 — chars in an IFC GUID
- 3 — max value of first char
- 0 bytes — uploaded to validate
- 100% — runs in browser
What a Stable GlobalId Is Supposed to Be
Every IFC entity that inherits from IfcRoot carries a GlobalId: a 22-character string using IFC's custom base-64 alphabet (0–9, A–Z, a–z, _, $). The spec is explicit that it should be globally unique and persistent — the same logical element keeps the same GlobalId across revisions and across software round-trips. That persistence is what makes change tracking, BCF, and asset registers possible.
// Revision 2
#1402 = IFCWALL('3LYa_FRDj3zhLfyYoQv6Jr', $, 'Exterior Wall - 300mm', ...);
// Revision 3 — same wall, regenerated GlobalId. Every reference to the old ID now dangles.
#1402 = IFCWALL('2hQ8pZ_a1ABxKm9dELc0Ru', $, 'Exterior Wall - 300mm', ...);
Why Revit Regenerates GUIDs
The root cause is that there is not always a clean one-to-one mapping between a Revit element and the IFC entity it exports to. A single Revit element can split into several IFC entities (a railing becomes a rail plus balusters plus a handrail), and when there is no stable 1:1 relationship, the exporter has no reliable anchor to derive a consistent GlobalId from. So it generates a fresh one.
Historically the IFC GUID parameter in Revit was read-only, which meant teams couldn't pin it even when they wanted to. Newer exporter versions made it read-write so the value can be stored and reused — but you still have to turn the right setting on, because the default behaviour on some configurations is to regenerate.
- Sub-element splitting: one host element exporting to multiple IFC entities (railings, stairs, curtain walls, roofs with fascias) is the classic source of drift.
- Re-export with 'generate new' behaviour: some export setups recreate GUIDs every time rather than reusing the stored value.
- Copy/paste and group edits in the authoring tool can reset the internal ID the GUID is derived from.
- Round-tripping through a tool that doesn't preserve GlobalIds (open-and-resave in a viewer or converter) rewrites them.
The Other Half: Invalid GUID Range
There's a related failure that hand-rolled export scripts hit constantly. The first character of a valid IFC GlobalId can only encode the values 0–3 in the 6-bit alphabet, because a 128-bit UUID packed into 22 base-64 characters leaves the leading sextet with only two significant bits. Scripts that take a plain 32-hex-character UUID and naively truncate or re-encode it produce a first character outside that range.
The GUID values are out of the valid range — if the first digit is anything other than 0, 1, 2 or 3, it is not a conformant IFC GlobalId.
buildingSMART Forums — common IFC export mistakes
An out-of-range GlobalId will be silently tolerated by lenient parsers and rejected by strict ones — so the same file 'works' in one tool and fails validation in another, which is maddening to diagnose without a checker that flags the range explicitly.
How to Detect Unstable or Invalid GUIDs
You can't see GUID drift by looking at a single file — you need to compare two exports, or check for invalid format and duplicates within one. Open both revisions in the validator: it flags GlobalIds that are out of the valid range, duplicated within a file, or malformed, in under 30 seconds, entirely in your browser. Nothing is uploaded.
Check GlobalIds in a real model
Open the buildingSMART duplex to see a clean GlobalId report, then drop in two consecutive exports of your own model to spot which elements had their IDs regenerated.
IFC2x3 · 2.4 MB
Open the interactive IFC viewer
How to Keep GUIDs Stable
Revit
Use the open-source IFC exporter, and in File → Export → IFC → Modify Setup → Advanced, set "Export IFC GUIDs" to "Keep Existing" (never "Generate New"). This reuses the stable GlobalId Revit stores per element instead of minting a new one each export. For elements that split into multiple IFC entities, accept that the sub-entities may not be perfectly stable — anchor your coordination on the host element's ID.
ArchiCAD
In the IFC Translator settings, enable "Write stable GlobalIDs (from AC internal IDs)". Without it, ArchiCAD derives GlobalIds in a way that can shift between exports.
Fixing what already drifted
If a file already contains invalid or duplicate GlobalIds, the validator can auto-fix them: it generates a fresh, spec-compliant 22-character GlobalId using the correct base-64 alphabet with a leading character in 0–3. Use this to repair a delivered file's format — but fix the export setting upstream too, or the next re-export reintroduces the drift.
Related reading on the duplicate-GUID case (two elements, one ID) and the full set of structural checks: see Duplicate GUIDs in IFC and The 7 Most Common IFC Validation Errors in this blog.
Why IFC GUIDs Change on Every Export (and How to Keep Them Stable)