Reduce BIM file size
Slim your discipline exports so federations load fast and CDE syncs stop crawling — duplicate geometry merged, dead entities swept, output verified, nothing uploaded.
Runs on your device — the model is never uploaded.
Drop your IFC file here
.ifc and .ifczip · IFC2x3, IFC4, IFC4x3
No file at hand? Try a sample: ·
- orphaned entities swept from a 2.3 MB sample house model
- 1,245
- of results re-parsed with web-ifc before download
- 100%
- bytes sent anywhere — the model stays on your machine
- 0
Measured by this site's automated QA suite on real project models — every figure is recorded before it is published.
When a BIM file is too large, the whole coordination cycle pays
Every coordination round starts the same way: each discipline exports its BIM model to IFC, everybody pushes to the CDE, and everybody else pulls the lot back down to federate. Multiply a bloated architectural export by an MEP model and a structural model, then by weekly clash cycles and a dozen team members, and oversized files stop being a storage nuisance — they become the slowest link in the loop. Uploads time out, downloads eat the morning, and the federated view takes ages to assemble on every machine that opens it.
The frustrating part is that much of that bulk is not design information at all. Authoring tools repeat identical coordinate points thousands of times and abandon entities that lost their last reference edits ago. This tool strips precisely that waste and nothing else: no element, property or relationship is ever altered, and because the whole pipeline is WebAssembly running locally, the file never leaves your browser — NDA-covered and tender-stage models included.
How it works
- Drop the export. Feed it a .ifc or a .ifczip straight from Revit, ArchiCAD, Tekla or any other authoring platform. The tool indexes the file and reports its schema and entity makeup before touching a single byte.
- Pick the cleanups. The orphaned-entity sweep hunts down data that nothing references; the duplicate-point merge is a separate toggle you can switch off if you want the sweep alone. Rooted objects and unrecognized entity types are excluded from removal, always.
- Download a verified file. Before the download unlocks, the rewritten IFC is re-opened with web-ifc — the identical engine our viewer runs on. Only a file that parses cleanly gets handed back to you.
What the cleanup touches — and what it never will
Repeated geometry points. A wall corner shared by four elements should be one coordinate in the file; many exporters write it four times, or four hundred. The dedup pass keeps a single instance per unique position and rewires every reference to it. The shapes on screen are bit-for-bit the same — the STEP text carrying them just got shorter.
Orphaned entities. Deleting elements during modelling leaves stranded placements, profiles and property definitions behind, and some export pipelines dump whole libraries nothing points at. The sweep traces what is actually reachable and discards the rest. In our 2.3 MB sample house it flagged 1,245 such orphans — roughly 71 KB of pure dead weight in a small file, and the pattern scales with model size.
Everything else: hands off. Any line the cleanup does not need to modify is emitted token-identical to your original, so a diff of input against output shows only the intended changes. Rooted entities — the walls, doors, spaces and relationships that make the model a model — can never be removal candidates, and neither can entity types the tool does not explicitly know. Conservative by rule, not by luck.
Shrink the IFC, convert it, or just view it?
Keep the file as IFC — and slim it here — whenever coordination is the goal: federating disciplines, running clash checks, pushing deliverables through a CDE with size limits, or archiving milestone snapshots. How much you save depends on the exporter, so treat the tool as a free experiment: worst case you lose a minute, best case every future sync of that model gets lighter. If the destination is a browser or a headset and the data payload is optional, converting the model to glTF cuts far deeper than any IFC cleanup can. If what you need is the information rather than the geometry, pulling the BIM data into Excel replaces the whole model with a workbook. And whichever route you take, the free BIM viewer opens the result in the same tab so you can confirm with your own eyes that nothing moved.
Frequently asked questions
Will a slimmed model break my clash detection or federation workflow?
It should not, and that is by design. The cleanup rewrites only the lines it actually changes; the rest of the file stays token-identical to what your authoring tool exported. Elements, spatial structure, property sets, quantities and relationships all come through untouched, so downstream coordination tools see the same model — just carried by fewer bytes.
What exactly gets taken out of the file?
Two categories of dead weight. First, repeated geometry points: exporters tend to write the same coordinate over and over, and the optional dedup pass collapses those repeats into a single shared point. Second, orphaned entities — leftovers that nothing in the model references anymore. Anything rooted (elements, spaces, relationships) and any entity type the tool does not positively recognize is left strictly alone.
How much can a discipline export actually shrink?
That depends almost entirely on which software wrote the file. Revit and ArchiCAD exports typically carry far more duplicate points than Tekla's, so an architectural or MEP model often slims down noticeably while a tidy structural export may barely move. Run it and the result screen tells you the honest before-and-after for your specific file.
How do I know the output is still a valid IFC?
Every result passes through a verification gate before you can download it: the rewritten file is re-opened with web-ifc, the same parsing engine behind our 3D viewer. If that second parse fails for any reason, the download is withheld and you see an error instead — a corrupted deliverable can never reach your CDE.
Does my model touch a server at any point?
Never. Parsing, analysis, rewriting and the verification pass all execute inside your browser via WebAssembly. Nothing is transmitted, cached remotely or stored — which means models under NDA, live tender packages and client-confidential designs can be processed without asking anyone for permission.
What schemas and file sizes does it accept?
All three current schemas — IFC2x3, IFC4 and IFC4x3 — are handled, and .ifczip archives are unpacked automatically. There is no enforced cap: around 300 MB is the practical ceiling on a desktop machine, a friendly warning appears past 150 MB, and on mobile devices the warning triggers earlier, at 80 MB combined.