How to View an Elasticsearch Index Mapping (and Actually Read It)

Updated July 2026 · Works with Elasticsearch 6.x–9.x

The mapping is the schema of an Elasticsearch index: every field, its type, and how it's analyzed. You need it constantly — to know whether a field is text or keyword, to find out why a query returns nothing, or just to see what's actually in an index someone else created. Here's how to get it, how to read it, and a faster way to browse it.

Getting the mapping with the API

# Mapping of one index
curl -s "http://localhost:9200/products/_mapping?pretty"

# Mappings of several indices, or a pattern
curl -s "http://localhost:9200/logs-*/_mapping?pretty"

# Every index on the cluster (can be huge)
curl -s "http://localhost:9200/_mapping?pretty"

On a secured cluster add -u user:password or an API-key header, same as any other request. If the response is overwhelming, filter_path trims it down — for example, just the field names and types:

curl -s "http://localhost:9200/products/_mapping?pretty&filter_path=*.mappings.properties.*.type"

Reading the JSON

A mapping response looks like this:

{
  "products": {
    "mappings": {
      "properties": {
        "name":     { "type": "text",
                      "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } },
        "price":    { "type": "float" },
        "in_stock": { "type": "boolean" },
        "brand":    { "type": "keyword" },
        "specs":    { "properties": {
                        "weight_g": { "type": "integer" },
                        "color":    { "type": "keyword" } } }
      }
    }
  }
}

The rules for reading it:

• properties holds the fields. A field with its own nested properties (like specs) is an object — its subfields are queried with dot notation: specs.color.
• text vs keyword is the distinction that matters most. text is analyzed for full-text search (match queries); keyword is stored as an exact value for filtering, sorting, and aggregations (term queries). Using term on a text field is the classic reason a query that "should" match returns nothing.
• The fields block means a multi-field. Above, name is text, and name.keyword is an exact-value copy — use name for search, name.keyword to sort or aggregate.
• Dynamic mapping fills in what you didn't define. If you never wrote a mapping, Elasticsearch guessed types from the first document — worth checking, because a numeric string like "123" becomes text, not a number.

The pain: real mappings are huge

The example above is 5 fields. A real logs or product index easily has hundreds, nested several levels deep, and answering a simple question — "do we have a field called customer_id, and is it a keyword?" — means scrolling a wall of JSON and mentally joining dotted paths.

Elasticvix, a free open-source Chrome extension, shows any index's mapping as a searchable field → type table instead: every field flattened to its full dotted path, with a filter box on top. Type customer, see every matching field and its type instantly. The same mapping also powers the extension's query console — autocomplete suggests your real field names as you type, and linting flags a field that isn't in the mapping before the query runs.

Quick reference

• One index: GET /index/_mapping
• All indices: GET /_mapping
• Only types: add ?filter_path=*.mappings.properties.*.type
• Full-text field: text · exact/filter/sort/agg field: keyword
• Multi-field: query name for search, name.keyword for exact