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 concerned about the extra information traveling 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 to understand what can be removed, what can only be updated, and what cannot be touched., to act precisely without breaking anything.

Throughout this guide, we've compiled, in one place, information scattered across various official Google documentation and help articles. You'll see how to remove tag metadata from a file, manage indexable text and thumbnails, and learn about limits and exceptions.Additionally, we've clarified common 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 removable (e.g. tags), 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. Tags can contain fields (text, user, etc.) and deleting them removes their associated information from that file.This deletion is performed via API with atomic operations.

Indexable text (contentHints.indexableText) is not "removed" as such with a button; is overwritten or left empty when you update the file resourceThis is content designed to improve the discoverability of file types that Drive doesn't natively index.

Custom thumbnails are managed in a similar way: You can upload another thumbnail image or stop providing it.If Drive can generate a standard thumbnail, it will use its own; if it can't, it will use the one you provide.

There are metadata that cannot be deleted in Drive, such as file size or internal timestamps. These system properties are updated by the service itself and do not support direct deletion..

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 limits: The maximum size of indexableText is 128 KB; capture terms and concepts that truly describe the content; don't try to sort the text by relevance; the indexer already prioritizes it; updates the text on every save; avoid keyword stuffing with unrelated keywords (it frustrates users and can encourage deletions).

Keep in mind that, since it is treated as HTML, Textual 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 do not 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.

Deleting metadata and deleting files are different actions. If you own a file and you move it to the trash, you're not clearing metadata: you're removing the file from your drive.The remove option (when you are not the owner) simply removes it from your view, but others will still see it.

Send a file to the trash on the web: go to drive.google.com, right click and select Move to TrashIf someone else is the owner, you'll see Remove. To permanently delete, empty the trash. Neither of these steps will "delete metadata" from the preserved file: Either delete the file or manage its metadata using the options explained.

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

When you work with the Storage Transfer Service to/from Cloud Storage, there are rules about what metadata is retained and what is not. This is key if you use Drive alongside 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 on one system will magically make it disappear on another.; respect the conservation rules for each transfer.

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

Although not Drive, many teams touch VM metadata in Compute Engine. To manage them you need appropriate IAM permissions and know 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 upper or lower case.

Scopes and precedence: The same key name can exist at the project and zone level, but the zonal value prevails in your areaIf you add a zonal value, it's used for VMs in that zone, even if there's a project-level value; adding a project value doesn't override the existing zonal value.

Common operations: you can configure project metadata (apply to all VMs), zonal metadata (affect all VMs in a zone in that project) and instance metadata (for one VM only). To delete, gcloud or REST allow remove project, zonal, or instance metadata as appropriate.

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 Drive footprint, focus on what's manageable: Tags (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 don't own it, remember that removing it from your view doesn't delete anything for others. Coordinate with the owner if the goal is to completely remove content or metadata. associates.

If you're integrating Drive with Cloud Storage streams or VMs, document expectations. Much metadata changes or does not travel between systems.; avoid automations that depend on timestamps or ACLs that are not preserved.

With these guidelines, you'll have control over what really makes a difference. Manage tags accurately, take care of what's indexable, and decide when and how to use thumbnails. to achieve a balance between privacy, search and user experience.