How to remove metadata in Google Drive: complete guide and special cases

Informatec Digital » The Cloud » How to remove metadata in Google Drive: complete guide and special cases

delete metadata on Google Drive

If you're worried about what extra information travels with your files in the cloud, you've probably wondered how to clean up or control that invisible data. In Google Drive, metadata ranges from tags and indexable text to thumbnails and file properties. The key is understanding what can be removed, what can only be updated, and what can't be touched , so you can act precisely without breaking anything.

Throughout this guide, we've gathered in one place information that's scattered across various official Google documentation and help articles. You'll learn how to remove tag metadata from a file, manage indexable text and thumbnails, and understand limits and exceptions . We also clarify similar scenarios (Cloud Storage transfers and VM metadata in Compute Engine) to avoid confusion if you're working with Google Cloud.

What is metadata in Drive and how far does the term go?

In Google Drive, metadata includes information such as name, MIME type, inferred extension, labels, indexable text, and associated thumbnails. Some pieces are editable or deletable (e.g., labels), others are updated indirectly (indexable text and thumbnails), and others cannot be deleted because they are part of the system (such as file size or internal creation and update dates).

You'll also see references to metadata in other Google Cloud products, such as Cloud Storage or Compute Engine. You should not confuse the metadata of a VM or object in Cloud Storage with that of a Drive file.; they share the concept, but their management and limits are different.
Manage metadata in Drive

What can actually be removed in Drive

From a practical standpoint, what is most commonly considered "removing metadata" in Drive is removing labels applied to a file. Labels can contain fields (text, user, etc.), and removing them deletes their associated information from that file . This deletion is performed via API using atomic operations.

The indexable text (contentHints.indexableText) isn't simply "deleted" with a button; it's overwritten or left empty when you update the file resource . It's designed to improve the discoverability of file types that Drive doesn't index natively.

Custom thumbnails are handled similarly: you can upload a different thumbnail image or stop providing one . If Drive can generate a standard thumbnail, it will use its own; if not, it will use the one you provide.

Some metadata in Drive, such as file size and internal timestamps, cannot be deleted. These system properties are updated by the service itself and cannot be directly deleted.

Remove labels from a file in Google Drive

The Drive API allows you to modify or remove labels using the method files.modifyLabels. The request includes an object of type ModifyLabelsRequest with one or more modifications that are applied atomically. (if any are not valid, nothing applies).

To completely remove a tag from a file, send a LabelModification with the label identifier and the erase instruction. This process removes all fields from that tag in the file.If you only need to disable a specific field, you can "unset" that field without removing the entire tag.

Conceptual steps to remove a tag from a specific file: 1) identifies the labelId of the label present in the file (you can list them with files.listLabels), 2) Submit the modification with removeLabel activated, 3) validates that the response includes the final state of the updated labels.

Indexable text: control, limits and good practices

If your app saves file types that Drive doesn't index alone (drawings, videos, shortcuts, etc.), you can increase searchability by filling in contentHints.indexableText. This text is processed as HTML, indexed, and may appear in results summaries. on more search surfaces.

Important recommendations and limitations: the maximum size of indexableText is 128 KB ; capture terms and concepts that truly describe the content; do not attempt to order the text by relevance, the indexer already prioritizes; update the text on each save ; avoid "padding" with unrelated keywords (it ends up frustrating users and may encourage deletions).

Keep in mind that, since it's treated as HTML, the text content is indexed, not attributes . For example, if your string includes tags with attributes, the visible text will be indexed, not the values ​​of those attributes.

Thumbnails: Upload, Replace, and Recover

Drive automatically generates thumbnails for Docs, Sheets, Slides, and other types. If your file type does not generate a standard thumbnail, you can provide one. Setting contentHints.thumbnail when creating or updating the file.

Requirements for custom thumbnails: Use PNG, GIF or JPG; recommended width 1600 px (minimum 220 px); maximum file size 2 MB; provides the URL-safe base64-encoded image and the mimeType Right. The thumbnail must be updated on every save, because it is invalidated when the file content changes (metadata changes alone do not invalidate it).

To retrieve the thumbnail, check the field thumbnailLink of the resource files. It is a short-lived link and only appears if your app can access the content.If the file isn't public, you'll need credentials to use that link.

Examples of querying metadata with thumbnails via REST:

GET https://www.googleapis.com/drive/v3/files/FILE_ID?fields=id,name,mimeType,thumbnailLink
GET https://www.googleapis.com/drive/v3/files?q=mimeType='application/vnd.google-apps.spreadsheet'&fields=files(id,name,mimeType,thumbnailLink)

File names and extensions: what you should know

When inserting a file via API, it is recommended to specify the extension in the property name (for example, cat.jpg). Drive will propagate that extension as fileExtension read-only in subsequent responses, and when the user downloads the file or syncs to the desktop client, the full name will be generated based on the title.

If you don't provide an extension, Drive will try to determine it from the MIME type . Whenever possible, specify it to avoid surprises.

Don't confuse removing metadata with deleting files.

Removing metadata and deleting files are different actions. If you own a file and send it to the Recycle Bin, you're not clearing metadata; you're removing the file from your drive . The delete option (when you're not the owner) simply hides it from you, but others will still see it.

To send a file to the trash on the web: go to drive.google.com, right-click, and select Move to trash . If someone else owns the file, you'll see Remove. To permanently delete the file, empty the trash. Neither of these steps removes metadata from the stored file: you either delete the file or manage its metadata using the options explained.

Cloud Storage metadata transfers and retention (in case you move data)

When working with the Storage Transfer Service to/from Cloud Storage, there are rules about which metadata is retained and which is not. This is key if you use Drive with buckets or migrate data between clouds.

From Amazon S3 or compatible to Cloud Storage

• They are conserved fixed-key metadata fields (e.g., Cache-Control, Content-Disposition, Content-Type).
• User-defined metadata is passed to custom metadata in Cloud Storage (editable).
• El ETag It is saved as personalized with the key x-goog-source-etag.
• Object size is preserved as size.
• S3 Access Control Lists and Object Tags: are not preserved.
• S3 Timestamp Metadata: are not preserved. In Cloud Storage, timeCreated y updated reflect the moment of creation/update at destination.
• Storage class: configurable during transfer (by default, that of the destination bucket).

From Microsoft Azure Blob to Cloud Storage

• Fixed key metadata fields: they are conserved.
• User-defined metadata: are saved as custom in Cloud Storage.
• ETag It is preserved as x-goog-source-etag.
• Size as size. ADLS Gen2 POSIX Permissions and Specific Access Control: are not preserved.
• Azure Timestamp Metadata: are not preserved. timeCreated/updated are recalculated at destination.
• Storage class: configurable as in the case of S3.

Between Cloud Storage buckets

• Fixed and custom key metadata: they are conserved.
• Object generation: saved as custom metadata x-goog-reserved-source-generation.
• Retentions: Temporary retentions are retained by default; event-based retentions are not. Beware of LCA: You can keep them, but avoid creating inaccessible objects.
• Storage class: Keep, set a new one, or use the one from the destination bucket.
• CMEK Encryption: optional to keep; by default the destination bucket method is used.
• timeCreated can be kept in customTime; updated No.
• Other non-editable metadata (e.g., etag, componentCount): No..

Lists of URLs to Cloud Storage

• Fixed key metadata fields: editable at destination.
• Content-Length y MD5: not editable and are preserved if the source provides them.
• Source timestamps: No.. Storage class: configurable.

POSIX to Cloud Storage (and vice versa)

• mtime persisted as custom metadata goog-reserved-file-mtime.
• Size is preserved as size. UID, GID, MODE and symlinks: optional via metadataOptions.
• In POSIX to POSIX, UID/GID/MODE can be preserved on files and folders; mtime It is saved for files (in folders the creation time at destination is used).

These details matter when moving data between services. Don't expect that deleting metadata in one system will magically make it disappear in another ; respect the retention rules of each transfer.

Compute Engine (VM) Metadata: Limits and Deletion, if you use Google Cloud

Although it's not Drive, many teams access VM metadata in Compute Engine. To manage this, you need the appropriate IAM permissions and knowledge of size and scope limits.

First of all: Install Google Cloud CLI and run it for the first time with gcloud init (If you use an external identity provider, log in federated.) Keep the CLI up to date with gcloud components update and set default region and zone to avoid scope errors.

Typical required permissions: If the VMs use service accounts, is required iam.serviceAccounts.actAs. For project-level metadata: compute.projects.get y compute.projects.setCommonInstanceMetadata. For zonal metadata: compute.instanceSettings.get y compute.instanceSettings.update. For metadata on a specific VM: compute.instances.get y compute.instances.setMetadata.

Key Limits: The metadata set per VM has a combined maximum of 512 KB; each key up to 128 bytes and each value up to 256 KB. SSH keys are stored in ssh-keys; if you exceed the limit, It's time to clean up unused keysIf you put startup/shutdown scripts as direct content, they count toward the limit; instead, save the script to Cloud Storage and provides only the URL.

Uppercase/lowercase: the keys are case sensitive; values ​​as well, except for booleans. For zonal metadata: only managed with gcloud or REST; You cannot duplicate keys with the same text by changing the case (e.g., create ZONAL-METADATA-KEY if zonal-metadata-key already exists); and you cannot define zonal values ​​for ssh-keys.

Booleans accept equivalents: TRUE/FALSE and alternatives such as Y/Yes/1 and N/No/0, without distinguishing between uppercase or lowercase letters.

Scope and precedence: The same key name can exist at both the project and zonal levels, but the zonal value takes precedence in its zone . If you add a zonal value, it is used for VMs in that zone even if there is a project-level value; adding a project value does not override existing zonal values.

Common operations: You can configure project metadata (applies to all VMs), zonal metadata (affects all VMs in a zone within that project), and instance metadata (only for one VM). To remove metadata, gcloud or REST allows you to delete project, zonal, or instance metadata as needed.

Using REST locally: The REST API samples use the credentials you provided to the gcloud CLI. Authenticate your environment and reuse those credentials to test calls from your machine.

Practical tips for better metadata hygiene in Drive

If you want to reduce your footprint in Drive, focus on what you can control: labels (remove them if they don't add value), indexable text (adjust or empty it if you don't need it), and thumbnails (replace them or avoid uploading them) . System properties are for auditing, not deleting.

When a file is shared and you're not the owner, remember that removing it from your view doesn't delete anything for others. Coordinate with the owner if the goal is to completely remove associated content or metadata.

If you integrate Drive with flows in Cloud Storage or with VMs, document expectations. Many metadata change or don't travel between systems ; avoid automations that rely on timestamps or ACLs that aren't preserved.

With these guidelines, you'll have control over what truly makes a difference. Manage tags precisely, control what's indexable, and decide when and how to use thumbnails to strike a balance between privacy, searchability, and user experience.