# json-ld.org: the site that carries the JSON-LD specification and its playground

> json-ld.org is the source for the JSON-LD website, which hosts the W3C specification documents, a browser playground for trying markup, and a directory of published contexts. It is a static Eleventy site on Cloudflare Pages with a CodeMirror 6 editor, and it is where the format's canonical context URLs are served from.

**json-ld/json-ld.org** — JSON for Linked Data's documentation and playground site

- Repository: https://github.com/json-ld/json-ld.org
- Website: https://json-ld.org/
- Stars: 921 · Forks: 165
- Language: HTML
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/json-ld-json-ld-org

## A specification site that also serves context documents

This repository is the source for the json-ld.org website, and the site does more than host prose. It is where the JSON-LD specification documents live, where the playground runs, and where the published context documents are served.

JSON-LD itself is described as a lightweight Linked Data format, easy for humans to read and write and easy for machines to parse and generate. It builds on ordinary JSON and gives a way to help JSON data interoperate at Web scale. The stated pitch to developers is a smooth migration path from the JSON you use today to the JSON-LD you will use in the future, which is why the format is described as an ideal Linked Data interchange language for JavaScript environments, Web services, and unstructured databases such as CouchDB and MongoDB.

The difference between plain JSON and JSON-LD is visible in the smallest possible example, which the site presents as a simple JSON object with added semantics.

```json
{
  "@context": "https://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
```

The @context key points at a remote document that defines what the terms mean, and the @id gives the subject a Web-wide identity. The point of the site, in other words, is that the context URL in that example resolves to something on json-ld.org, and the repository carries a contexts/ directory to publish exactly that kind of document.

## The playground, and why it needs a proxy for http URLs

The playground at json-ld.org/playground/ is the interactive part of the site, a place to try JSON-LD markup without writing any code.

The new playground is built with CodeMirror 6 and integrated into the surrounding UI with petite-vue. The repository layout separates the concerns across two files: playground/next/index.html holds the HTML and the petite-vue markup level code, while playground/next/editor.mjs contains the JavaScript that sets up CodeMirror and attaches it to the DOM via petite-vue.

The build step for that editor uses esbuild to produce the browser ready bundle at _site/playground/next/editor.bundle.js, and it also generates a CSS bundle at _site/playground/next/editor.bundle.css holding the editor styles.

The detail that will trip up anyone trying to reproduce this locally is the proxy. The playground has a special proxy to handle http: URLs, and that proxy is implemented as a Cloudflare Pages Function. The site is deployed on Cloudflare Pages, so the function only exists inside that environment, which is why the local development instructions include running the Wrangler server to emulate the Cloudflare Pages Functions code.

In short, the playground is a static front end plus a server side piece that the hosting platform provides. Running it on your own machine without emulating that platform means the http: fetching path behaves differently.

## Building the site locally with Eleventy and serving it with Wrangler

The site is published with Eleventy and deployed on Cloudflare Pages. The README gives four commands for local development.

```sh
# install dependencies
npm i
# to just build the static files to `_site/`
npm run build
# to rebuild the files on changes
npm run watch
# to serve `_site/` with Cloudflare Pages feature support
npm run pages # visit http://localhost:8788/
```

The build script chains the editor bundle with the static site generation, running the esbuild step first and then eleventy. The watch script runs eleventy in watch mode so the static files are rebuilt on change, and the pages script starts wrangler pages dev against the _site directory so you get Cloudflare Pages feature support locally rather than a plain static file server.

If you want to exercise the playground's http: proxy as well, there is a separate command.

```sh
npm run dev
```

That runs wrangler pages dev with live reload on port 8788, which is what the README describes as emulating the Cloudflare Pages Functions code. The two serving commands exist for different reasons, pages for previewing the built output with platform features, dev for the live reload loop against the functions.

The project is declared as an ES module with type set to module and marked private, so it is not published to npm. The dependency list tells you what the site is built from: Eleventy at 3.1.5, the CodeMirror 6 packages, petite-vue at 0.4.1, esbuild at 0.27.7, wrangler at 4.80.0, d3 at 7.9.0, markdown-it-anchor and markdown-it-attrs, yaml at 2.8.3, and two JSON-LD specific packages, jsonld at 9.0.0 and jsonld-vis pinned to a semver range of a GitHub branch.

## Two Google Analytics identifiers, because the site predates a single tracking property

The site has used Google Analytics since 2013 and still carries two GA identifiers rather than one.

The first, UA-40462488-1, covers the primer/, spec/ and requirements/ sections. The second, UA-42886053-1 is the default and applies to everything else. The default can be overridden per page by setting ga to a specific number in that page's front matter.

The split is a historical artefact of how the site grew, and it is instructive for anyone who maintains a long-lived documentation site. Sections written and launched at different times ended up with different analytics properties, and rather than consolidating them, the pattern became a per-page override in the front matter. The identifiers themselves are the old Universal Analytics format, and the file names primer/, spec/ and requirements/ also tell you that this site predates the current W3C specification process and covers much more than the specification documents.

The repository layout confirms the scope. Beyond the spec/ directory there is primer/, requirements/, learn/, ns/ for namespaces, contexts/, schemas/, examples/ split into api, framing, playground and syntax, presentations/, static/, images/, fonts/, a test-suite/, benchmarks/, a scripts/ directory and a functions/ directory for the Cloudflare Pages Functions that back the playground proxy. There are also _data/, _includes/, _layouts/ and _redirects, plus a test-redirects.js file and a wrangler.toml at the root.

The examples directories mirror the specification documents, with a separate folder per specification area, which is how conformance examples are usually organised so that each one can be traced back to the clause it tests.

## Where this repository stops and the specification begins

The important thing to understand about json-ld.org is that it is a website repository, not an implementation. There is no JSON-LD processor here that you call from your application. The jsonld and jsonld-vis packages in the devDependencies exist to support the site itself, including the visualisation that the playground can show, not to offer a runtime API.

The specifications themselves are W3C documents, and the site links them: JSON-LD 1.1, A JSON-based Serialization for Linked Data, JSON-LD 1.1 Processing Algorithms and API, and JSON-LD 1.1 Framing. A list of all previous specification drafts is also available, and the spec/ directory in the site serves the specification text under json-ld.org/spec/.

That distinction has a practical consequence. If you want to process JSON-LD in a JavaScript application, the format itself is standardised and the site is where you read the rules, but the library that implements those rules is a separate dependency, and the compatibility question becomes which implementation you use rather than which site you read. A reading of the site cannot tell you how a particular processor expands a context, because the specification defines the algorithm while the processor executes it.

The site also has a user directory. The introduction asks anyone already using JSON-LD to add themselves to the list of users in the project wiki, which is a reasonable indicator of how broad adoption is, and a community chat on Gitter is linked from the top of the README.

One more limit is worth naming. The site is hosted on Cloudflare Pages, so it inherits that platform's availability and configuration rather than being self hosting in a conventional sense. You can build and serve it locally, but the canonical deployment is a Pages project.

## Licence, versioning and how to contribute

The licence field on the repository says Other, a custom licence GitHub cannot classify, with a pointer to the LICENSE file, and the repository carries a LICENSE.md at the root alongside a CONTRIBUTING.md.

Because the site publishes context documents that other systems link to by URL, the licence question has a specific shape. A context at json-ld.org/contexts/ is fetched by third party code at runtime, and the terms attached to redistributing or modifying those documents are what a legal review should look at rather than the terms attached to running the website. This is not legal advice, but it is the reason the classification is worth checking rather than assuming MIT or similar from the GitHub metadata alone.

The repository has no GitHub releases, so there is no version history to point at and no tag to pin. The last push was on 2026-06-17, so the site is still being worked on, but the state of the deployed site and the state of the default branch are the same thing in practice, since the deployment is driven by the repository rather than by a release artefact.

For contributors, the workflow is ordinary for an Eleventy site: install with npm i, run npm run watch while editing, and use the local Wrangler serving commands when a change touches the playground proxy. The repository also carries a .editorconfig file, an .npmrc file and a .eleventy.js configuration at the root, which is where the Eleventy specific settings live.

The test script in the package manifest is a placeholder that echoes Error: no test specified and exits with status 1, so there is no automated test suite to run before a change. The test-redirects.js file and the test-suite/ directory are content assets rather than a test runner.

## Conclusion

json-ld.org suits anyone who needs the authoritative text of the JSON-LD 1.1 specification, a way to try markup in a browser without installing anything, or a stable place to publish a context document that other systems will link to. It is not a library, so it does not suit a team looking for a JSON-LD processor to call from application code, and the repository is a website rather than a service, so there is nothing to deploy beyond the site itself. Before adopting anything from this repository, check that the JSON-LD 1.1 specification documents and the framing and API documents are the versions your stack targets, and if you publish a context there, confirm the licence file allows redistribution, since the licence field on the repository says Other and points at LICENSE.md.

## FAQ

### What is the JSON-LD playground at json-ld.org?

It is a browser playground for trying JSON-LD markup, at json-ld.org/playground/. The new version is built with CodeMirror 6 and integrated into the site UI with petite-vue, with the editor bundled by esbuild.

### How do I build the json-ld.org site locally?

Run npm i to install dependencies, then npm run build to generate the static files into _site/, npm run watch to rebuild on changes, and npm run pages to serve _site/ with Cloudflare Pages feature support at http://localhost:8788/. Running npm run dev additionally emulates the Cloudflare Pages Functions code through Wrangler.

### Why does the JSON-LD playground need a proxy?

The playground has a special proxy to handle http: URLs, and it is implemented as a Cloudflare Pages Function. The site is deployed on Cloudflare Pages, so the function only exists inside that platform, and local work on the proxy requires emulating it with Wrangler.

### Where are the JSON-LD 1.1 specifications published?

The site links the official W3C documents: JSON-LD 1.1, A JSON-based Serialization for Linked Data, JSON-LD 1.1 Processing Algorithms and API, and JSON-LD 1.1 Framing. A list of all previous specification drafts is also available at json-ld.org/spec/.

### Can I use json-ld.org as a JSON-LD processing library?

No. The repository is the source for the documentation and playground website, not a runtime implementation. The jsonld and jsonld-vis packages in its devDependencies support the site itself rather than offering an API for application code.

## Sources

- [Issues](https://github.com/json-ld/json-ld.org/issues)
- [json-ld/json-ld.org on GitHub](https://github.com/json-ld/json-ld.org)
- [Project website](https://json-ld.org/)
- [README](https://github.com/json-ld/json-ld.org/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/json-ld-json-ld-org