Label metadata in Office documents

When a document is labeled with a sensitivity label that has been created and published in Microsoft Purview, Office automatically embeds metadata that identifies which label was applied, how it was applied, and which tenant it belongs to. This metadata is the key to understanding how sensitivity labels work in practice. For Office documents, the metadata is stored as part of the document itself.

Office documents such as .docx and .pptx are essentially containers made up of a set of files. A .docx file can easily be extracted using tools such as 7-Zip, or by simply renaming the file extension from .docx to .zip and unpacking the contents. Among the extracted files, we can find information related to the sensitivity label applied to the document.

Modern storage structure for label metadata

Before examining the label metadata itself, it is important to be aware that Microsoft changed how label metadata is stored in Office documents a few years ago. Previously, label metadata was stored in the file’s custom properties. This approach caused challenges and limitations related to co-authoring and simultaneous editing of documents.

To address this, Microsoft introduced a new setting in Purview in 2023 to enable co-authoring for files with sensitivity labels. You can find this setting in Purview under Settings → Information Protection:

When this setting is enabled, label metadata is no longer stored in the file’s custom properties. Instead, it is written to a dedicated folder called docMetadata. Inside this folder, you will find the file labelinfo.xml, which contains fields such as id (the label ID) and siteId (the tenant ID).

This modern storage format is only used when co-authoring is enabled, and it is this configuration that we use as the basis for the examples in this article. In most environments, this setting should be enabled unless you have custom scripts or solutions that depend on the legacy label metadata format.

Label metadata for unencrypted documents

Let’s start by extracting a document labeled with the sensitivity label “Open”. This label is not configured with access control, so the document is not encrypted.

We can then open the docMetadata folder:

Next, we open the labelinfo.xml file:

The metadata fields have the following meaning:

  • label id. The GUID of the sensitivity label applied to the document.
  • siteId. The Entra ID tenant ID where the sensitivity label was created and published.
  • method. Indicates how the label was applied. Standard means the label was applied automatically, either because it was configured as the default label or through auto-labeling. Privileged means the label was applied manually by the user.

Label metadata for encrypted documents

Next, let’s examine a document labeled with the sensitivity label “Confidential”. This label is configured with access control (only users in the same tenant are allowed to decrypt and read the content), which means the document is encrypted.

In this case, the document consists of a different file structure:

If we open the [6]DataSpaces folder, we find the file LabelInfo:

Opening the LabelInfo file reveals similar metadata fields as in the unencrypted example.

Label metadata across tenants

So far, we have looked at how label metadata is stored within a single tenant. When a user labels a document with a sensitivity label, other users in the same tenant will see the label exactly as it is configured in Purview. Everything works as expected—as long as all users belong to the same tenant.

But what happens when a user in tenant A sends a labeled document to a user in tenant B?

In this scenario, the user in tenant B does not see the original label, because the label belongs to a different tenant. To the recipient, the document therefore appears unlabeled. The user in tenant B can then apply a new sensitivity label from their own tenant.

As a result, the document now contains two label entries in its metadata—one for each tenant. The example below illustrates exactly this: a document that carries label metadata from both tenant A and tenant B.

Documents that are sent back and forth between tenants may therefore appear to have different labels depending on which tenant the document is opened in.