Evaluate JMESPath
Expressions Online

Query your JSON in four steps

No account. No upload. No nonsense.

Related JSON tools

Common questions answered

What is JMESPath?

JMESPath (JSON Matching Expression Paths) is a query language for JSON with a compact expression syntax for extracting and reshaping data. JMESPath powers the --query flag in the AWS CLI, making it essential for cloud engineers who filter command output daily. Its specification is formally defined and tested across Python, JavaScript, Go, and other languages.

This evaluator lets you test JMESPath expressions interactively. JMESPath supports projections (extracting fields from arrays), multi-select (building new objects), filters, slicing, and functions like length(), sort_by(), and contains(). It is more powerful than JSONPath for data reshaping but has a steeper learning curve.

// Data
{"people":[
  {"name":"Alice","age":30},
  {"name":"Bob","age":25},
  {"name":"Charlie","age":35}
]}

// Query: people[?age > `28`].name

["Alice", "Charlie"]

Get the most out of this tool

• Use people[*].name to project a single field from an array of objects — a common pattern in AWS CLI output.
• Multi-select creates new structures: {name: name, count: length(items)} builds a new object from results.
• The pipe operator (|) chains expressions: people | [0] gets the first element after a projection.

Understanding JMESPath — the JSON query language

JMESPath (JSON Matching Expression paths) is a query language for extracting and transforming data from JSON documents. Created by James Saryerwinnie, JMESPath is defined by a formal specification that has been implemented in Python (the reference implementation), JavaScript (jmespath.js), Java, Ruby, Go, PHP, and Lua. Unlike JSONPath, which has varying implementations with inconsistent behavior, JMESPath's specification-driven approach ensures that a valid JMESPath expression produces identical results across all compliant implementations.

The AWS CLI uses JMESPath as its --query parameter, making JMESPath one of the most widely encountered JSON query languages for DevOps and cloud engineers. Commands like aws ec2 describe-instances --query "Reservations[*].Instances[*].InstanceId" use JMESPath to extract specific fields from AWS API responses. This makes JMESPath fluency a practical skill for anyone working with AWS, Azure CLI, and other cloud CLIs that adopted the same query syntax.

JMESPath's identifier syntax uses dot notation for object field access: foo.bar.baz navigates from the root to nested fields. Array subscripts use bracket notation: people[0] accesses the first element. The wildcard [*] projects over all elements of an array, while the object wildcard * projects over all values in an object. Multi-select lists [a, b] and multi-select hashes {key: a} create new structures from existing data.

Filter expressions are JMESPath's most powerful feature for data extraction. The syntax [?condition] filters an array to elements matching the condition. For example, people[?age > `30`] returns only people with age greater than 30. Conditions can use comparison operators (==, !=, <, >, <=, >=), logical operators (&&, ||, !), and the contains() function for substring and array membership tests.

JMESPath pipe expressions chain multiple operations using the | operator. The output of the left expression becomes the input of the right expression. For example, people[?active] | [0] filters to active people and then takes the first result. The sort_by() function enables sorting arrays: sort_by(people, &age) sorts by the age field. The & prefix creates an expression reference used as a sort key rather than evaluating the expression immediately.

Built-in JMESPath functions transform values during query evaluation. length(array) returns element count. keys(object) returns an array of object keys. values(object) returns an array of object values. join(',', array) concatenates array strings. min_by() and max_by() find minimum and maximum elements by a field. to_string() and to_number() convert between types. These functions enable significant data transformation without requiring a programming language.

The JMESPath compliance test suite provides hundreds of test cases that implementations must pass to be considered compliant. This test suite is the foundation of JMESPath's cross-implementation consistency — before an implementation can be certified, it must pass all compliance tests. When choosing a JMESPath library for production use, verify it references the official compliance test suite, ensuring that expressions written in one environment will behave identically in another.

Real-world uses for JMESPath queries

JMESPath expression pitfalls

• Comparing to bare strings instead of quoted strings: In JMESPath filter expressions, literal strings must be enclosed in single quotes: [?type == 'active']. Writing [?type == active] (without quotes) attempts to compare to an identifier named "active", not the string literal "active", producing unexpected results.
• Confusing JMESPath with JSONPath syntax: JSONPath uses $ as the root identifier and @ in filter expressions; JMESPath uses neither. JMESPath filters use [?condition] without @, and the root is implicit. Expressions from one language will not work in the other — verify which query language your tool uses before writing expressions.
• Forgetting backticks for literal numbers in filters: JMESPath filter literal numbers must be enclosed in backticks: [?age > `30`]. Omitting backticks causes the number to be interpreted as an identifier rather than a numeric literal, making the comparison fail silently.
• Not handling null results from missing fields: JMESPath returns null (not an error) when a field does not exist. Chaining operations on a null result will also produce null rather than an error. Build null checks into downstream code or use the || '' default value pattern in AWS CLI queries to handle missing fields gracefully.

Additional frequently asked questions