Online Testers and Validators for Developers
Test regular expressions, JSONPath queries, and XML documents with focused online developer tools.
Choose a tool
Test with representative input, not one happy path.
Three tools sit here and they answer three different shapes of question. Regular Expression Tester asks whether a pattern matches what you think it matches and what it captures. JSONPath Tester asks whether an expression selects what you think it selects, against a real document. XML Validator asks the blunter question of whether markup is well-formed at all, and where it stops being so.
Two exploratory tools and one verdict
Regular Expression Tester and JSONPath Tester are both iteration loops: you keep the expression beside its sample data, change one, and watch what happens to the matches. That loop is only as good as the sample, which is why the useful sample is the one containing the values that must not match, the empty case, and the malformed case.
XML Validator is the opposite. There is nothing to iterate on: the document is well-formed or it is not, and when it is not the position of the first failure is the whole answer. Use it when you have been handed a file and need to know whether the markup itself is the problem before you look anywhere else.
JSONPath Tester against JSON to Table
Both pull values out of a JSON document, and the wrong one gets picked often. Use the JSONPath Tester when you are developing an expression that some other system will run later, such as a log pipeline filter, a configuration selector, or a CI assertion, and you need to see exactly what it selects and what it silently skips.
Use JSON to Table, under Converters, when you simply want to look at the data or export it as CSV. That is a reading task, not an expression-authoring task, and a table answers it in one step without anyone having to maintain a path expression afterwards.
Be precise about which engine you are testing
A regular expression is not portable the way people assume. Lookbehind, named groups, Unicode property escapes, and the meaning of the dot under multiline flags all differ between JavaScript, PCRE, Python, Go, and the regex support inside a database. A pattern proven here still has to be re-run where it will actually execute.
JSONPath has the same problem in a smaller form, since the filter and slice syntaxes vary by implementation. And for XML, well-formed and schema-valid are distinct claims: the validator confirms that tags nest and that reserved characters are escaped, while conformance to an XSD or a DTD needs a schema processor.
Before you rely on a result
- Include inputs that should not match, not only the ones that should. A pattern with no negative cases has not been tested.
- Run a regular expression against the empty string, multi-line input, Unicode text, and the longest realistic value you expect.
- Watch for nested quantifiers. A pattern that backtracks catastrophically on a long non-matching string is a denial of service, not a bug you will notice on a short sample.
- Test JSONPath against a document with a missing field and an empty array, because those are the cases that silently return nothing at all.
- Re-run the final expression in the engine that will execute it in production before you call it done.
Frequently asked questions
Does a passing test mean my expression is correct?
It means the sample you supplied behaved as expected under the engine used here. Correctness is a claim about every input the expression will ever see, which no single sample can establish. Add the awkward cases deliberately: empty, missing, duplicated, oversized, and wrongly typed.
Why does my regex behave differently in my application?
Because regex flavors genuinely differ. The tester runs the JavaScript engine, so lookbehind, named groups, Unicode escapes, and flag semantics may not match PCRE, Python, Go, or your database. Use the tester to reason about the pattern, then confirm it where it will run.
What is the difference between well-formed and valid XML?
Well-formed means the syntax holds up: tags nest correctly, every element is closed, and reserved characters are escaped. Valid additionally means the document matches a declared schema. XML Validator answers the first question, and a document can pass it while still being rejected by an XSD.
Is my test data sent anywhere?
No. All three tools evaluate in this browser tab, and nothing is uploaded or kept between visits. Sample documents pulled from production often contain real identifiers and tokens, so replace them before pasting rather than relying on local processing as permission.
Browse all developer tools or read the developer tool guides for worked examples.