JSON Pointer tester: evaluate RFC 6901 pointers

What is a JSON Pointer?

A JSON Pointer is a short string that names exactly one place in a JSON document. It is a sequence of tokens, each introduced by a solidus, so /paths/~1users/get walks from the root into the member called paths, then into the one called /users, then into get. RFC 6901 defines it in eight pages, and it is what JSON Patch, JSON Schema references and OpenAPI all use to say where they mean.

The important word is exactly. A pointer names one location, and either it is there or it is not — which is what separates it from JSONPath, where a single query can match a hundred nodes or none, and where different implementations return different sets. There is nothing to disagree about in a pointer, which is precisely why the formats that need to be unambiguous chose it.

That small grammar has a surprising number of edges, and this tool shows all of them. Paste a document, write a pointer, and it evaluates one token at a time: what each token was looked up in, what it found, and — when nothing was found — which rule stopped it.

How to use it

1. Paste a document. It starts with the example document printed in the standard, so every answer the tool gives can be checked against RFC 6901 itself. Anything that is not valid JSON is reported rather than guessed at.
2. Write a pointer. The empty string names the whole document; everything else begins with a solidus. Inside a token, a tilde is written ~0 and a solidus ~1. Or pick one from the list of every pointer in your document at the bottom.
3. Read the trace. Each row shows one token, whether it was looked up in an object or an array, and what came back. A failure names the specific rule instead of just reporting nothing.

The escaping rule, and the order it has to happen in

Two characters cannot appear literally inside a token. A solidus would start a new token, and a tilde is the escape character, so they are written ~1 and ~0. That is the whole escaping scheme, and it is smaller than most people expect: there is no backslash, no percent-encoding, and no other escape at all. A tilde followed by anything except 0 or 1 is not a valid pointer.

What makes it interesting is the order. Decoding must turn ~1 into a solidus first and ~0 into a tilde second. Do it the other way round and ~01 becomes ~1 and then a solidus, when the correct answer is the two characters ~1. The standard spends a whole paragraph on that, naming the wrong result explicitly — which is a good sign that real implementations have got it wrong. This tool decodes in a single pass, so the hazard is not avoided by remembering an order, it simply cannot arise.

Encoding runs the other way and has the same trap in reverse: escape the tilde first, then the solidus, or a name containing a solidus produces a token that decodes back to something else. The tool escapes as it goes for the same reason.

Four rules that surprise people

An array index may not have a leading zero. The grammar allows a bare zero, or a digit from one to nine followed by any digits, and nothing else — so /foo/01 is a syntax error rather than index one. This is exactly where a JavaScript implementation goes wrong, because both of the obvious ways to read a number accept it: one of them turns the text 01 into the number one, and the other reads a leading number out of 1abc and discards the rest. Neither is what the grammar says.

A lone solidus is not an empty pointer. It is one token whose name is the empty string, so it points at the member called nothing at all — a perfectly legal JSON member name, and one the standard's own example document includes for exactly this reason. The empty pointer, with no characters at all, is the one that names the whole document.

The single character - names the position after the last element of an array. It is not an index, and there is never a value there; it exists so that JSON Patch can say append here. Reporting it as an error would be wrong and reporting a value would be a lie, so the tool gives it its own answer.

Member names are compared by code point, and the standard states plainly that no Unicode normalization is performed. Two spellings of the same accented letter — one composed into a single character, one written as a letter followed by a combining mark — look identical on screen and are different members. If a pointer that looks right refuses to resolve, that is worth checking before anything else.

The fragment form, and what it does not mean

A pointer can also be written into a URI fragment, and the standard gives the same twelve examples again in that form: the pointer is encoded as UTF-8 and anything a fragment cannot carry is percent-encoded, so a per cent sign becomes %25 and a space becomes %20. The tool shows that spelling for whatever you type and lets you copy it.

Then comes the sentence most readers would not predict, in the same section that prints those examples: the fragment identifier syntax for application/json is not JSON Pointer. A media type has to declare JSON Pointer as its fragment syntax explicitly, and plain JSON never did. So a URL ending in a pointer is meaningful inside a JSON Schema or an OpenAPI reference, where the format says it is, and decorative on an ordinary .json file, where nothing gives it that meaning.

The limits of the tool are worth stating too. It evaluates pointers and does not apply patches; RFC 6902 builds on this grammar to add, remove and move values, and that is a different job. It works on the document you paste rather than following references out to other files. And it is deliberately strict: where a library might quietly accept a leading zero or a stray tilde, this reports the rule that was broken, because a pointer that works in one implementation and fails in another is the problem it exists to prevent.

Why is it free?

Walking a document one token at a time is a few hundred lines of string handling, and your browser does it as you type. No server sees your JSON, so there is nothing to meter and no account to create.

Nothing is uploaded. Whatever you paste stays in this tab.