Supported data types (Azure AI Search)

In Azure AI Search, document fields and values in expressions (for example, in filters) are typed according to the Entity Data Model, or EDM (see Entity Data Model for details).


If you're using indexers to pull data into Azure AI Search, indexers have different data type mappings for JSON and SQL Server data sources. For more information, see Data type map for indexers in Azure AI Search.

EDM data types used in Azure AI Search indexes and documents

Specifying EDM data types is necessary when defining fields in an index. You can find examples of JSON representation for fields of various types in Create Index examples. For an example of JSON documents contained typed content in data upload scenarios, see Add, Update or Delete Documents examples.

Data type Description
Edm.String Text data.
Edm.Boolean Contains true/false values.
Edm.Int32 32-bit integer values.
Edm.Int64 64-bit integer values.
Edm.Double Double-precision IEEE 754 floating-point values.
Edm.DateTimeOffset Date and time values represented in the OData V4 format: yyyy-MM-ddTHH:mm:ss.fffZ or yyyy-MM-ddTHH:mm:ss.fff[+|-]HH:mm. Precision of DateTimeOffset fields is limited to milliseconds. If you upload DateTimeOffset values with submillisecond precision, the value returned is rounded up to milliseconds (for example, 2015-04-15T10:30:09.7552052Z is returned as 2015-04-15T10:30:09.7550000Z). When you upload DateTimeOffset values with time zone information to your index, Azure AI Search normalizes these values to UTC. For example, 2017-01-13T14:03:00-08:00 is stored as 2017-01-13T22:03:00Z. If you need to store time zone information, add an extra field to your index.
Edm.GeographyPoint A point representing a geographic location on the globe. For request and response bodies, the representation of values of this type follows the GeoJSON "Point" type format. For URLs, OData uses a literal form based on the WKT standard. A point literal is constructed as geography'POINT(lon lat)'.
Edm.ComplexType Objects whose properties map to subfields that can be of any other supported data type. This type enables indexing of structured hierarchical data such as JSON. Objects in a field of type Edm.ComplexType can contain nested objects, but the level of nesting is limited. The limits are described in Service limits.
Collection(Edm.String) A list of strings.
Collection(Edm.Boolean) A list of boolean values.
Collection(Edm.Int32) A list of 32-bit integer values.
Collection(Edm.Int64) A list of 64-bit integer values.
Collection(Edm.Double) A list of double-precision numeric values.
Collection(Edm.Single) A list of single-precision IEEE 754 floating-point values, used exclusively in Create or Update Index (2023-07-01-Preview) for vector fields.
Collection(Edm.DateTimeOffset) A list of date time values.
Collection(Edm.GeographyPoint) A list of points representing geographic locations.
Collection(Edm.ComplexType) A list of objects of type Edm.ComplexType. There's a limit on the maximum number of elements across all collections of type Edm.ComplexType in a document. See Service limits for details.


All of the above types are nullable, except for collections of primitive and complex types, for example, Collection(Edm.String). Nullable fields can be explicitly set to null. They are automatically set to null when omitted from a document that is uploaded to an Azure AI Search index. Collection fields are automatically set to empty ('[]' in JSON) when they are omitted from a document. Also, it is not possible to store a null value in a collection field.

Unlike complex collections, there is no upper limit specifically on the number of items in a collection of primitive types, but the 16 MB upper limit on payload size applies to all parts of documents, including collections.

Edm.GeographyPolygon is a polygon representing a geographic region on the globe. While this type can't be used in document fields, it can be used as an argument to the geo.intersects function. The literal form for URLs in OData is based on the WKT (Well-known text) and OGC's simple feature access standards. A polygon literal is constructed as geography'POLYGON((lon lat, lon lat, ...))'.

To learn more about geospatial search in Azure, see this video: Azure AI Search and Geospatial Data


Points in a polygon must be in counterclockwise order. Points in a polygon are interpreted in counterclockwise order, relative to the inside of the polygon. For example, a 4-point closed polygon around London would be -0.3°W 51.6°N [top left] , -0.3°W 51.4°N [bottom left], 0.1°E 51.4°N [bottom right], 0.1°E 51.6°N [top right], -0.3°W 51.6°N [starting point].

See also