# jsonpath-online-evaluator: a browser playground for JSONPath expressions

> jsonpath-online-evaluator is a single-page app for trying JSONPath expressions against a JSON document in the browser, with a Monaco editor, a generated parser and two third-party JSONPath engines. It ships as static files you can host yourself, a Docker image, and a Codespaces-ready development setup.

**ashphy/jsonpath-online-evaluator** — JSONPath Online Evaluator

- Repository: https://github.com/ashphy/jsonpath-online-evaluator
- Website: https://jsonpath.com/
- Stars: 699 · Forks: 146
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/ashphy-jsonpath-online-evaluator

## A playground for one query language

The project is described in one line as a playground for JSONPath, and that framing tells you exactly what to expect. It is a place to type an expression and see what it selects from a JSON document, not a library and not a service. The topics list is a single entry, jsonpath, and the primary language is TypeScript. The application itself is a React front end: react 19 and react-dom 19, vite as the build tool, Tailwind CSS 4 through the PostCSS and Vite plugins, and a stack of Radix UI primitives for the dialogs, popovers, selects, switches and tooltips, with cmdk for the command palette, jotai for state, valibot for validation and lucide-react for icons. The document editing is handled by @monaco-editor/react, which is the single largest decision in the dependency list, because a JSONPath playground is only useful if writing and reading a large JSON document is comfortable. The live instance is at jsonpath.com.

## Two JSONPath libraries and a generated parser

The dependency list contains both jsonpath-js at 0.3.1 and jsonpath-plus at 10.4.0, which is a choice worth understanding rather than glossing over. The two libraries implement the same idea with different dialects, and the README does not say which one drives the interface. A separate entry is jsonc-parser at 3.3.1, which handles JSON with comments, and that matters because the document you paste is often a fragment of a configuration file rather than a strict JSON payload. The most interesting entry is the parser the project generates itself. The package scripts include a build:parser step that runs peggy with a configuration at src/lib/JSONParser/config.cjs, and peggy is the only dev dependency listed without a version range. Peggy is a parser generator, so the application ships a purpose-built grammar for the JSONPath syntax rather than validating expressions with a regular expression, which is why the app can point at a specific character in a malformed expression. The parser is generated as a build artifact, so the grammar source is what you edit when the syntax needs to change.

## Running it with Docker in one command

The README offers a public Docker image, and the command is short:

```bash
 $ docker run -d -p 8080:80 ashphy/jsonpath-online-evaluator:latest
```

The port mapping publishes container port 80 on host port 8080, so the playground is then reachable on that port. The Dockerfile in the repository is a two-stage build that makes the shape of the artefact obvious. The first stage is node:22-bullseye-slim named webpack, which copies the checkout into /app, runs npm install and then npm run build. The second stage is nginx:1.27.3-bookworm, which copies the built dist directory into the nginx html root. So the image contains no Node.js runtime and no application server: it is nginx serving static files. The practical consequence is that the container has no runtime configuration surface, no database and no background work, which makes it trivial to run, and equally means there is nothing to scale or tune beyond the static file cache headers.

## Hosting the static files yourself

If you would rather not run a container, the other hosting path is the simplest one imaginable. The README's Private Hosting section says to download at releases, and the release artefacts are the built static site. The build script in the manifest is tsc -b followed by vite build, so the output in the dist directory is what you copy onto any web server or object store. Because the application is entirely client side, there is no backend to configure and no origin to allow-list, and the privacy story follows from that: a JSON document you paste into the playground does not leave your browser, which is the point of a tool for testing expressions against payloads that may contain data you would rather not upload to a third party. The page-level metadata in the manifest carries a homepage of ./, which is the setting that makes the built site work when it is served from a subdirectory rather than a domain root, which is the usual case for a self-hosted static deployment.

## Development on Codespaces or locally

The README points first at a Codespaces badge, which is the fastest way to get a working environment since the repository ships a .devcontainer directory and a .vscode directory. Otherwise the local path is three commands:

```bash
  $ npm install
  $ npm run dev # Starting the dev server
  $ npm run build # Building the static files
```

The only stated requirement is node.js. The scripts around those three are a test script running vitest, a lint script running eslint over the project, a preview script running vite preview, and the build:parser step described earlier. The presence of a vitest script and a CI workflow badge in the README header suggests the expression handling and the parser are covered by tests rather than checked by hand, and the .github directory and infra/ directory at the root of the repository suggest the deployment of the live site is scripted in the same place. The package is marked private in the manifest, so nothing here is published to npm: this is a website, not a reusable module, and the only way to consume the code is to read it or run it.

## The parts a playground cannot tell you

There are limits that come with the form factor rather than the implementation. A playground shows you what an expression selects, and it does not tell you how your own library will interpret the same expression, which matters because JSONPath dialects differ in how they handle filters, recursive descent, script expressions and the treatment of keys that look like array indices. With two JSONPath engines in the dependency list and no documentation of which one the interface uses, a result on screen is evidence about the expression, not about your stack. Second, the app is a single document and a single expression, so there is no batch evaluation over many files, no way to save a query library, and no way to diff two expressions. Third, the features around the query are the ones you would expect in a client-side tool: the document is parsed in the browser, so an enormous JSON file is a performance question, and the README documents nothing about size limits. None of this is a criticism of the project, which does not claim to be a production tool. It is a reminder of what a playground is for, which is learning the syntax and checking a candidate expression before you put it in real code.

## Maintenance, licence and who wrote it

The project is MIT licensed, stated in the README and in the manifest and with a LICENSE file at the root, and the author is Kazuki Hamasaki. The releases are v3.5.2 on 2026-03-04, v3.5.1 on 2025-12-30 and v3.5.0 on 2025-09-15, all on a 3.5.x line, and the last push to the repository was on 2026-06-01. The version numbering carries information. A patch release three months after a minor one, and a patch release four months before that, is the shape of a project in maintenance rather than in active feature development, and the 3.5 line held steady across all three releases. For a hosted utility that is an entirely reasonable posture, since the tool is a frontend for query syntax and the syntax itself is stable. It does mean that if you are pinning this image in your own infrastructure, the tag moves with each patch release and the upstream site is the thing to watch, not the repository activity.

## Conclusion

jsonpath-online-evaluator suits a developer who needs to check a JSONPath expression against a real document quickly, whether to learn the syntax or to debug an expression that a service is rejecting, and self-hosting it is a matter of copying static files or running one container. It is the wrong tool if you need library-grade guarantees about which JSONPath dialect your expression follows, because the app depends on both jsonpath-js and jsonpath-plus and the README does not document which one the interface uses, and it is the wrong tool for anything larger than a playground, since there is no API, no saved queries and no batch evaluation. Verify first that the results match the engine your own code uses, because a JSONPath expression that works here can still fail in the library that matters, and note that the last push to the repository was on 2026-06-01 with the newest release v3.5.2 from 2026-03-04.

## FAQ

### How do I run the JSONPath Online Evaluator with Docker?

Run docker run -d -p 8080:80 ashphy/jsonpath-online-evaluator:latest. The image is a two-stage build whose final stage is nginx serving the built static files, so there is no application server or database to configure.

### Can I host the JSONPath evaluator myself without Docker?

Yes. The README's Private Hosting section points to the releases page for the built static files, and the build is tsc -b followed by vite build, producing a dist directory you can serve from any web server.

### What is the build:parser script for?

It runs peggy with the configuration at src/lib/JSONParser/config.cjs, so the project generates its own JSONPath grammar as a build artifact rather than validating expressions with a regular expression.

### What do I need to develop the project locally?

Node.js. You run npm install, then npm run dev for the dev server or npm run build for the static files, with npm test running vitest and npm run lint running eslint. The README also links a Codespaces badge for a preconfigured environment.

### Which JSONPath implementation does the evaluator use?

The manifest lists both jsonpath-js and jsonpath-plus as dependencies, and the README does not state which one the interface relies on, so the dialect used on screen is worth confirming against the library your own code uses.

## Sources

- [ashphy/jsonpath-online-evaluator on GitHub](https://github.com/ashphy/jsonpath-online-evaluator)
- [License: MIT](https://github.com/ashphy/jsonpath-online-evaluator/blob/master/LICENSE)
- [Project website](https://jsonpath.com/)
- [README](https://github.com/ashphy/jsonpath-online-evaluator/blob/master/README.md)
- [Releases](https://github.com/ashphy/jsonpath-online-evaluator/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ashphy-jsonpath-online-evaluator