BCF 2.1 vs BCF 3.0: what's the difference?

Quick answer: BCF 3.0 is a stricter, more structured evolution of BCF 2.1 — not a different format. BCF 2.1 was released in October 2014 and BCF 3.0 in June 2021, both by buildingSMART International. The main changes in 3.0 are that project values (statuses, types, priorities) are stored as regular data rather than in an XSD extension schema, and that required fields, documents and viewpoints are defined more precisely. Both use the .bcf extension, so the filename tells you nothing — a bcf.version file inside the archive declares the schema. In practice, pick the version every tool in your workflow can open.

BCF 2.1 and BCF 3.0 serve the same basic purpose: they exchange BIM issues between different applications without carrying the full model.

Both versions can contain topics, comments, viewpoints, snapshots and references to model elements. BCF 3.0 is not a completely different format. It is a more structured and stricter evolution of BCF 2.1.

For most teams, the practical question is simple: which version can every tool in the workflow open correctly?

What do BCF 2.1 and BCF 3.0 have in common?

The coordination workflow remains largely the same.

A BCF file can describe an issue, record its status and priority, include a discussion and save a viewpoint that takes the reviewer back to the relevant part of a model.

Both versions use the .bcf file extension. The filename alone does not tell you which version you have; a small bcf.version file inside the archive declares the schema used by the package.

This is why BCF 2.1 and BCF 3.0 may look almost identical in a viewer. The main differences sit in how the data is structured, validated and exchanged between applications.

What changed in BCF 3.0?

BCF 3.0 focuses mainly on consistency. It defines project values, required fields, documents and viewpoints more clearly than BCF 2.1.

 

Project values are stored as regular data

BCF projects often use their own lists of statuses, types, priorities, users, labels and stages. In BCF 2.1, these values were typically defined in an extension schema called extensions.xsd, referenced by project.bcfp.

XSD stands for XML Schema Definition. Think of it as a rulebook that tells software which values are allowed. In BCF 2.1, values such as Open, In Progress and Closed were written as allowed options inside that rulebook.

BCF 3.0 separates the rulebook from the actual project data. The standard schema remains fixed, while the project’s statuses, types and other lists are stored directly in extensions.xml.

In simple terms:

• BCF 2.1: the allowed values are written into a custom XSD schema;
• BCF 3.0: the allowed values are listed as ordinary XML data.

This is easier for applications to read and exchange because they no longer need to interpret a modified validation schema just to discover which statuses or users belong to the project.

 

Required fields are more clearly enforced

BCF 2.1 allowed a topic to exist without a TopicType or TopicStatus. In BCF 3.0, both values are required.

This improves consistency, but it also means that converting an older file to BCF 3.0 may reveal missing information. A conversion tool may need to ask the user to choose a type or status before the new file can be created.

BCF 3.0 also applies clearer rules to required text values: a required field cannot simply be present but empty.

 

Project information is simpler

BCF 2.1 used project.bcfp for two purposes: it could describe the BCF project, but it also pointed to the extension XSD. Because the project element itself was optional, the file could exist only to reference the schema.

In BCF 3.0, extension values have moved to extensions.xml. If project.bcfp is included, it contains the project information and requires a non-empty ProjectId.

The ProjectId identifies the BCF project that the topics belong to. It is not an IFC model identifier.

 

Documents have a defined project-level structure

BCF 2.1 could reference documents stored with individual topics or at external locations, but project-level document packaging was less structured.

BCF 3.0 introduces an optional documents.xml file and a dedicated Documents folder. Each stored document has a GUID, while its original filename and description are recorded separately.

This gives applications a clearer way to store a document once and reference it from the relevant topics.

 

Issue IDs work better with server platforms

Every BCF topic has a GUID, but long technical identifiers are inconvenient in meetings and everyday communication.

BCF 3.0 adds the optional ServerAssignedId. It allows a server to give an issue a short, project-specific identifier such as STR-142, while the GUID continues to provide its permanent technical identity.

This is particularly useful when BCF files move between desktop applications and cloud-based issue management systems.

 

Viewpoints are described more precisely

BCF 3.0 adds an aspect ratio to orthographic and perspective camera definitions. It also defines the perspective field of view as a vertical angle and expands its valid range from the narrow 45–60 degrees used in BCF 2.1 to any value between 0 and 180 degrees.

The newer specification also formally allows both PNG and JPEG snapshots.

These changes give applications more information for reproducing the original view, although the result still depends on how well each viewer implements the standard.

Which BCF version should you use?

Use BCF 2.1 when compatibility is the priority, especially when the project includes older or more established BIM tools.

Use BCF 3.0 when every application in the workflow supports it and you want stricter validation, simpler project extensions, formal document handling and better support for server-based issue identifiers.

Do not choose a version only because its number is higher. A valid BCF 3.0 file is not useful if the receiving application only understands BCF 2.1.

On projects that use several platforms, the safest version is usually the newest one supported reliably by all of them.

Can BCF 2.1 and BCF 3.0 be converted?

Yes, but conversion involves more than changing the version number.

When converting from BCF 2.1 to 3.0, project values must be moved from the XSD structure into extensions.xml, and missing required fields may need to be completed.

When converting from BCF 3.0 to 2.1, those project values must be represented again through an extension schema. Some newer information, such as ServerAssignedId or the BCF 3.0 document structure, may not have a direct equivalent in the older format.

The main issues, comments and viewpoints can usually be preserved, but the converted file should still be checked in the application that will receive it.

Convert BCF 2.1 and 3.0 with Bimlyte

Bimlyte can open both BCF 2.1 and BCF 3.0 and export the issues in the version required by another application.

To convert a file, add it to a Bimlyte project, open the BCF file menu and choose Export as, then select BCF 2.1 or BCF 3.0. If the target version requires information that is missing, Bimlyte asks you to complete it before creating the file.

The conversion happens locally in your browser. The BCF file and its project data are not uploaded to a server.

Read the step-by-step guide on how to convert BCF between 2.1 and 3.0, or open Bimlyte and export the version your workflow needs.