JMESPath Playground

Query and transform JSON with JMESPath, the specified JSON query language used by the AWS CLI, boto3, the Azure CLI and many other tools.

Input JSON
Query Result

JMESPath Quick Reference

🔍 Basic Expressions

  • field — field access
  • a.b.c — nested access
  • arr[0] — array index
  • arr[-1] — last element
  • arr[*] — wildcard
  • arr[2:5] — slice

🔧 Built-in Functions

  • length(arr) — count
  • keys(obj) — object keys
  • values(obj) — object values
  • sort(arr) — sort array
  • sort_by(arr, &field)
  • min_by / max_by
  • to_string / to_number
  • contains(arr, val)

⚡ Projections & Filters

  • arr[*].name — list projection
  • arr[?x == `val`] — filter
  • arr[*].{a: x, b: y} — object
  • arr[*].[x, y] — multi-select list
  • a || b — or expression
  • arr[] — flatten

About JMESPath

JMESPath is a query language for JSON with a formal specification and a shared compliance test suite. It is used natively by the AWS CLI (--query flag), the Python boto3 SDK, the Azure CLI, Ansible (json_query) and numerous integration platforms. (RFC 9535 is a different standard: it defines JSONPath.) Unlike JSONPath, JMESPath has a formal specification with no ambiguity, making it ideal for reliable, reproducible data extraction in scripts and automation pipelines.

This playground uses jmespath.js, the JavaScript implementation of the JMESPath specification. It passes the same compliance tests as the Python library used by the AWS CLI, so expressions behave the same way.

Frequently Asked Questions

Where would I actually use a JMESPath expression?

The most common place is the AWS CLI's --query flag — for example aws ec2 describe-instances --query "Reservations[*].Instances[*].InstanceId" uses exactly the syntax you can test here. It also shows up in Ansible's json_query filter and any tool built on boto3 or the AWS SDKs.

How do filters work?

A filter expression like people[?age > `30`] keeps only the array elements where the condition after ? evaluates to true — note that literal values (numbers, strings, booleans) inside a filter must be wrapped in backticks, which trips up most people the first time.

What does the multi-select syntax {a: x, b: y} do?

It reshapes each matched element into a new object with only the fields you name — useful for trimming a large API response down to just the two or three fields your script actually needs, without writing a separate transformation step.

JMESPath vs jq vs JSONPath — which should I learn?

If you already work with AWS tooling, JMESPath is unavoidable and worth learning directly. For general-purpose shell scripting, jq's pipe-based syntax tends to read more naturally. JSONPath is the lightest-weight option and is well-supported directly in JavaScript/Java libraries. All three solve the same core problem with different syntax trade-offs.

JMESPath expressions you will use most

JMESPath shines in the AWS CLI, where the --query option trims large responses down to exactly what you need. A few expression patterns cover most everyday tasks.

Tips and common pitfalls

  • Reservations[].Instances[].InstanceId flattens nested lists into one list of IDs.
  • Items[?Status == 'active'].Name filters and projects in one step. String literals use single quotes, while backticks mark JSON literals such as `10`.
  • sort_by(Items, &CreatedAt)[-1] returns the newest item.
  • Add --output text or --output table to the AWS CLI to print the query result without JSON formatting.

More questions

Why does my filter fail or return nothing?

Check literal quoting. Numbers and booleans must be JSON literals in backticks, as in Size == `10`, while plain strings use single quotes. Double quotes mean a field name, so Status == "active" compares two fields.

Is JMESPath standardized?

Yes. It has a formal specification and compliance tests, so the same expression behaves the same in Python, JavaScript, Go and other implementations.