Object metadata

Go to examples

This page discusses the metadata fields that are stored along with objects in Cloud Storage.

Introduction

Objects stored in Cloud Storage have metadata associated with them. Metadata identifies properties of the object, as well as specifies how the object should be handled when it's accessed. Metadata exists as key:value pairs. For example, the storage class of an object is represented by the metadata entry storageClass:STANDARD. storageClass is the key for the metadata, and all objects have such a key associated with them. STANDARD specifies the value this specific object has, and the value varies from object to object.

The mutability of metadata varies: some metadata you can edit at any time, some metadata you can only set at the time the object is created, and some metadata you can only view. For example, you can edit the value of the Cache-Control metadata at any time, but you can only assign the storageClass metadata when the object is created or rewritten, and you cannot directly edit the value for the generation metadata, though the generation value changes when the object is replaced.

Editable metadata

There are two categories of metadata that users can change for objects:

  • Fixed-key metadata: Metadata whose keys are set, but for which you can specify a value.

  • Custom metadata: Metadata that you add by specifying both a key and a value associated with the key.

When editing metadata, you should generally avoid non-ascii characters, because they are not permitted in HTTP headers, which the XML API uses. When using the XML API, there is also a 16 KB limit to the combined size of the request URL and HTTP headers, so the total size of your metadata should take this limit into account.

Fixed-key metadata

You can edit the following metadata for objects, though you must have sufficient permission to do so:

Access control metadata

Cloud Storage uses Identity and Access Management (IAM) and Access Control Lists (ACLs) to control access to objects. Use these links to learn about these access control methods and associated metadata.

Cache-Control

The Cache-Control metadata can specify two different aspects of how data is served from Cloud Storage: whether the data can be cached and whether the data can be transformed.

Caching data

The Cache-Control metadata allows you to control whether and for how long browser and Internet caches are allowed to cache your objects, which can then be served to satisfy future requests. Cache-Control only applies when accessing objects that:

Cloud Storage respects standard values for Cache-Control, such as the following:

  • public: the object may be cached anywhere.

  • private: the object may be cached in a requester's local cache.

  • no-cache: the object may be cached, but cannot be used to satisfy future requests unless first validated by Cloud Storage.

  • no-store: the object should not be cached anywhere.

  • max-age=TIME_IN_SECONDS: the length of time an object may be cached before it's considered stale. You can set max-age to any length of time. Stale objects are not served from caches, except in special circumstances.

If an applicable object doesn't have a Cache-Control metadata entry, Cloud Storage uses the default value of:

  • public, max-age=3600.

If you allow caching, downloads may continue to receive older versions of an object, even after uploading a newer version. This is because the older version remains "fresh" in the cache for a period of time determined by max-age. Additionally, because objects can be cached at various places on the Internet, there is no way to force a cached object to expire globally. If you want to prevent serving cached versions of publicly readable objects, set Cache-Control: no-store on the object.

For more information about caching with Cloud Storage and Cloud CDN, see Caching.

Transforming data

Cache-Control metadata also allows you to serve objects as they are stored, without applying any transformations to the data, such as removing gzip content-encoding for incompatible clients. To serve an object as-is, set Cache-Control:no-transform.

Content-Disposition

The Content-Disposition metadata specifies presentation information about the data being transmitted. Setting Content-Disposition allows you to control presentation style of the content, for example determining whether an attachment should be automatically displayed or whether some form of action from the user should be required to open it. See https://datatracker.ietf.org/doc/html/rfc6266 for the Content-Disposition specification.

Content-Encoding

The Content-Encoding metadata can be used to indicate that an object is compressed, while still maintaining the object's underlying Content-Type. For example, a text file that is gzip compressed can have the fact that it's a text file indicated in Content-Type and the fact that it's gzip compressed indicated in Content-Encoding. You should ensure that files are, in fact, compressed using the specified Content-Encoding before uploading them, or else unexpected behavior can occur when attempting to download the objects. For more information, see the Transcoding page.

For compressible content, such as text, using Content-Encoding: gzip saves network and storage costs and improves content serving performance. However, for content that is already inherently compressed, such as archives and many media formats, applying another level of compression and marking it in the Content-Encoding metadata is typically detrimental to both object size and performance and should be avoided.

Content-Language

The Content-Language metadata indicates the language(s) that the object is intended for. Refer to ISO 639-1 language codes for the supported values of this metadata.

Content-Type

The most commonly set metadata is Content-Type (also known as media type), which lets browsers render the object properly. All objects have a value specified in their Content-Type metadata, but this value does not have to match the underlying type of the object. For example, if the Content-Type is not specified by the uploader and cannot be determined, it is set to application/octet-stream or application/x-www-form-urlencoded, depending on how you uploaded the object. For a list of valid content types, see the IANA Media Types page.

Custom-Time

The Custom-Time metadata is a user-specified date and time represented in the RFC 3339 format YYYY-MM-DD'T'HH:MM:SS.SS'Z' or YYYY-MM-DD'T'HH:MM:SS'Z' when milliseconds are zero. This metadata is typically set in order to use the DaysSinceCustomTime condition in Object Lifecycle Management.

You cannot remove Custom-Time once it's been set on an object. Additionally, the value for Custom-Time cannot decrease. That is, you cannot set Custom-Time to be an earlier date/time than the existing Custom-Time. You can, however, effectively remove or reset the Custom-Time by rewriting the object.

Object holds

Use metadata flags to place object holds, which prevent objects from being deleted or replaced. For more information, see the Object holds page.

Custom metadata

Custom metadata is metadata that you can add and remove. To create custom metadata, you specify both a key and a value. After you have created a custom metadata key:value pair, you can delete the key or change the value. Custom metadata is subject to a size limit and incurs storage costs.

The Viewing and Editing Metadata page includes information about setting custom metadata.

The x-goog-meta- prefix

The XML API sets and retrieves object metadata using request headers. In order to clearly distinguish custom metadata headers from standard request headers, the XML API prefixes custom metadata headers with x-goog-meta-.

Some tools that use the XML API also apply this convention. For example, when setting custom metadata with gsutil, you must include the x-goog-meta- prefix. Note that gsutil removes the prefix when you use it to view an object's metadata.

Non-editable metadata

Some metadata cannot be edited directly. This metadata is set at the time of object creation or rewrite. As part of the object creation or rewrite, you can set some such metadata, such as the storage class of the object or customer-managed encryption keys. Other metadata is automatically added and can only be viewed, such the generation number of the object or the time of creation.

What's next