About this tool
Before writing assertions in code, it helps to try them against a real response and see which pass. Paste a JSON body, optionally the status code and headers copied from DevTools or curl -i, and define checks in a table: a JSONPath exists or not, equals a value, has a type, matches a regex, contains an item, has a length, or is greater or less than a number. Status checks accept exact codes or classes like 2xx, and header names are matched case-insensitively. Results are shown like a test runner, with ✓ and ✕ rows and a “3 passed, 1 failed” summary you can copy into a bug report. JSONPath is evaluated with script evaluation disabled, so filter expressions are rejected instead of executed. Response time cannot be measured from pasted text, so that check is reported as skipped.
How to use it
- Paste the response body JSON, and the status and headers if you want to check them. Or click “Load sample”.
- Add checks: choose a target, enter a JSONPath such as $.data[*].email or a header name, pick an operator and an expected value.
- Read the results as you type and copy the report. Paths that match several values must pass for every match.
API Response Validator FAQ
Why does my filter expression like $..[?(@.price > 10)] fail?
Filter and script expressions require evaluating code, which this tool disables for safety. Use wildcard paths such as $.items[*].price with an operator like “>” instead: every matched value must pass.
How is the expected value interpreted?
If it parses as JSON it is compared as JSON, so 42 is a number, "42" is a string, true is a boolean and null is null. Anything else is compared as plain text. Equality on objects and arrays ignores key order.
Can I turn these checks into automated tests?
Yes. Once the checks pass, use the API Assertion Builder to generate equivalent Playwright, Postman, REST Assured or Cypress assertions.