Keep Only Physical IFC, RVT Elements

Keep walls, floors, columns, rebar, and MEP — remove spaces, zones, annotations, grids, proxies, and other non-physical objects.

Besides IFC, this tool takes Revit (.rvt) files, with no Revit licence. Drop one in and it is converted to IFC first, then the tool runs on that IFC; your original file is not changed.

Strip an IFC model down to what is physically built. Upload the model and get back the walls, floors, columns, beams, rebar and MEP — with the spaces, zones, annotation, grids, proxies and other non-physical objects removed in one pass.

Most IFC exports carry two models in one file: the building, and the apparatus of designing it. Spaces and zones describe rooms that have no material existence. Grids and annotation are drawing infrastructure. Proxies are whatever the exporter couldn't classify. All of it is legitimate in the authoring context and pure overhead in a coordination, fabrication or visualisation hand-off — where it inflates the file, clutters the element tree, and produces clashes against things that aren't there.

When to reach for it: When you want to keep only the real building content — walls, floors, columns, beams, rebar, MEP — and drop spaces, zones, annotations, grids, and proxy markers.

What you get: An IFC containing only physical building elements. Spaces, grids, annotations, and other non-physical objects are removed.

Example: Prepare a model for quantity takeoff by removing IFC spaces, grids, and annotation markers.

One decision instead of a list

The alternative is naming every class you don't want, which means knowing what the model contains, keeping the list current as exports change, and getting it right every time. This inverts that: it keeps what is physical and drops the rest, so a class you'd never heard of that the exporter invented is handled without you having to notice it.

The run reports both numbers — how many physical elements were kept and how many non-physical ones were removed — so you can see the shape of what happened rather than diffing two files to find out.

When this is the right tool, and when it isn't

It's right when the recipient needs the construction: a fabricator, a contractor, a clash run against another discipline, a visualisation, an export to a 3D or CAD format. In all of those, spaces and grids are noise at best and false positives at worst — a clash detection run that reports a duct passing through a space is reporting the room doing its job.

It's wrong when the recipient needs the rooms. An area takeoff, a space-program check, an FM handover and a room data sheet all read IfcSpace, and a model stripped of spaces returns nothing to any of them — correctly, and unhelpfully. If you need both outputs, run this on a copy rather than on the model you keep.

For a more surgical version, Delete IFC Elements removes exactly the classes you name, and Clean IFC Drawing Layers strips 2D helper representations while keeping the elements themselves.

Where it sits in a hand-off

This is usually the first step in an outgoing pipeline, because everything after it gets cheaper: fewer elements to optimise, fewer to tessellate, fewer to export. A typical chain is keep-physical → reduce size → export, saved as a pipeline so the whole sequence re-runs on each new revision instead of being reassembled by hand.

Using it on Revit files

When you open a .rvt file here, BIMCamel converts it to IFC on the server and brings you back to this tool with the converted model loaded. Element ids, levels and properties come across under their Revit names, so pick properties as they appear in your model. Your .rvt itself is never edited: a tool that changes the model gives you an IFC back.

It isn't offered for Navisworks files: it has nothing to remove: converted Navisworks models have no openings or spaces, and their connection points come through as ordinary elements.

Revit files can be up to 25 MB without an account, 100 MB with a free one and 200 MB on a paid plan. Revit projects saved in Revit 2021 to 2027 are supported.

How to keep only physical elements in an IFC model

  1. Upload your model (IFC or RVT)
  2. Click Run — no configuration needed
  3. Download the cleaned file

Under the hood

BIMCamel parses IFC files in the browser using the open-source web-ifc engine and renders models with @thatopen/components + three.js. Heavy operations (clean / optimise / validate / convert) run on disposable server-side workers using the same web-ifc stack plus our own .NET pipeline; results stream back to your browser as soon as they're ready. Uploads sit on our servers only as long as your tier's retention window allows and are never used to train AI.

Frequently asked questions

How do I remove spaces and zones from an IFC file?

Run this tool — it keeps the physically-built elements and removes spaces, zones, annotation, grids, proxies and other non-physical objects in one pass, and reports how many of each it kept and dropped.

Why remove spaces before clash detection?

Because a space is a volume, not an object, so anything passing through it registers as an intersection. A clash run against spaces reports every duct in every room — technically correct and completely useless. Stripping them first removes a large class of false positives.

What counts as non-physical?

Spaces, zones, annotation, grids, proxies and similar objects that describe or organise the design rather than being built. The tool keeps what's physical rather than blacklisting names, so a class your exporter invented is handled without you having to know about it.

Will this break my area takeoff?

Yes — area takeoff, space-program checks, FM handover and room data sheets all read IfcSpace, and a stripped model returns nothing to them. Run this on a copy when you need both the coordination model and the room data.

Is this the same as deleting elements?

It's the inverse. Delete IFC Elements removes the classes you name; this keeps what's physical and drops everything else. Use this when the goal is "just the construction" and the other when you have a specific list.

Which IFC versions are supported?

IFC2x3 and IFC4 — the two schema versions exported by essentially every AEC authoring application. IFC4x3, the infrastructure schema, works too: it opens in the viewer, and validation, health reports, property-set editing and georeferencing all run on it. Tools that need geometry processing, such as clash detection and 3D export, aren't verified on IFC4x3 yet.

What's the maximum IFC file size?

Up to 25 MB as a guest, 100 MB with a free account, 500 MB on Pro, and 1 GB on Team. The caps are on upload size only — every tool itself is available on every tier.

What happens to my file after processing?

Your file is uploaded over HTTPS and processed on our servers. Guest uploads are stream-only — the working files are deleted as soon as your download finishes. Free accounts keep results for 7 days; Pro and Team keep saved models until you delete them. Files are never shared with third parties or used to train AI.

Is Keep Only Physical IFC Elements free?

Yes. Keep Only Physical IFC Elements is free to use — guests get 3 runs a day with 25 MB uploads, and a free account raises that to 10 runs a day with 100 MB uploads. No trial clock, no watermarks.

Can I use a Revit file with Keep Only Physical IFC, RVT Elements?

Yes. Open a .rvt file and it is converted to IFC first; the tool then runs on that IFC and your original file is not changed. It isn't offered for Navisworks files: it has nothing to remove: converted Navisworks models have no openings or spaces, and their connection points come through as ordinary elements.

Guides from the Learn library

Related tools