json-everything: a set of .NET libraries for the JSON specifications

One package per specification, not one package for JSON

The json-everything project is described as System.Text.Json-based support for all of your JSON needs, but the shape of the deliverable is more interesting than that phrase suggests. There are actually multiple boxes, and each piece of functionality has been broken out into its own library, so you can pick and choose the one or ones you need. All of the libraries are built to.NET Standard 2.0 and to.NET 8, 9 and 10. The primary language is C#, the licence is MIT, and the last push was on 2026-10-17. The repository root confirms the scale of the operation, with a solution file, a `src/` directory, a `Meta-Schemas/` directory holding the schema documents themselves, a `ref-repos/` directory for reference implementations, a `json-everything.net/` directory for the playground site, a `doc-tool/` directory and a `tools/` directory. There is also a `json-everything.snk` file, the strong name key, and a `submodule-update.cmd` script, which tells you the reference repositories are pulled in as git submodules. The homepage is json-everything.net.

The rule against duplication, stated as a philosophy

The primary philosophy behind json-everything is to ensure that common JSON functionality has good support in the System.Text.Json space, and the way that philosophy is applied is worth reading closely. The first step is checking whether there exist other projects that support a given function. If so, that effort likely will not be duplicated here, and a list of other projects doing cool things with JSON is published further down the README. Otherwise, it is open to consideration for this project. That is an unusual and arguably admirable amount of self-restraint for a library collection, and it has a direct practical consequence. If you go looking for a JSON tool in this project and cannot find it, the likely reason is that another project already does it, not that the maintainer overlooked it. The topics list carries the same range, with json, json-e, json-logic, json-patch, json-path, json-pointer, json-schema, jsonschema-validator and yaml2json, which reads as an index of the specification space rather than a set of feature names.

JsonSchema.Net, and the draft versions that matter

The first library in the table is JsonSchema.Net, for JSON Schema, drafts 6 and higher. The draft number is the detail that changes behaviour rather than just compatibility, because the specification changed substantially between the early drafts, and a schema written against one draft can validate differently under another. The version range is also a deliberate exclusion of the oldest drafts, which is a reasonable position given how rarely they are written by hand today. A second package, JsonSchema.Net.Generation, sits next to it, which is the code generation side, the part that produces schemas from your types rather than validating against one. The repository root has a `.json-schema-identification.json` file, which is the document that maps a schema URL to its specification draft, and that file is exactly what a validator needs to decide which dialect a schema is written in when the schema itself does not say. The `Meta-Schemas/` directory holds the meta-schemas used to validate schemas, which is the step that catches a schema which is itself malformed.

The supporting tools around the schema library

A validator is only one part of working with JSON under a specification, and the ecosystem around it fills in the rest. The repository carries a `ref-repos/` directory of reference implementations, which is what a test suite can compare against, and the CI badges in the README point at a Build and Test workflow with a published test-results badge, which is the practice of a library that treats conformance as the product. The site at json-everything.net is a playground, and the documentation at docs.json-everything.net, the blog at blog.json-everything.net and the interactive learning material at learn.json-everything.net are the four entry points the README lays out. There is also a Stack Overflow tag and a Slack community, and the project says it is made with JetBrains ReSharper and is supported by the Open Source Maintenance Fee. The presence of a paid maintenance sponsor is a signal about the project's health, since that programme exists to fund exactly the kind of long-lived dependency that quietly stops being maintained.

Why System.Text.Json is the constraint that shapes everything

Every library in the family is built on System.Text.Json, and that single decision explains most of the design choices. The .NET JSON stack of the last several years has been split between Newtonsoft.Json, which predates it and is not part of the base class library, and System.Text.Json, which is the in-box option and is what a new .NET project reaches for first. A specification library has to pick one of those worlds or support both, and picking Newtonsoft would mean the library could not be used in an application that has deliberately moved away from it. The cost of that choice is that the APIs are shaped by what System.Text.Json can express, in particular the `JsonNode` model, and that a consumer who needs Newtonsoft's object model will find friction at the boundary. For a .NET team that has standardised on the in-box stack, that friction does not exist, and for one that has not, the choice of this family over a Newtonsoft-based equivalent is the first thing to check.

What to check before you depend on it

Three things. First, the target frameworks, because.NET Standard 2.0 and.NET 8, 9 and 10 is a narrower set than a package supporting every.NET version, and it means the packages do not run on.NET Framework and only run on.NET Core 3.1 or later. Second, the specification draft your existing schemas use, since JsonSchema.Net covers drafts 6 and higher and a schema written against an earlier draft will need attention. Third, the boundary between what this project covers and what it defers to someone else, since the duplication rule means a capability you expected here may live in a different library entirely, and you would be combining two packages rather than one. The project also publishes a Code of Conduct and an OSMFEULA.txt file in the root, the latter being the terms of the Open Source Maintenance Fund's sponsorship, and the repository has a `json-everything.sln.DotSettings` file, which is the ReSharper settings file shared across contributors, so the project is developed with a consistent IDE configuration. The last push was on 2026-10-17 and the repository has no GitHub releases, so the packages are versioned on NuGet rather than through repository tags.

Editorial conclusion

Adopt json-everything if your .NET application needs one of the JSON specifications implemented faithfully on top of System.Text.Json, especially JSON Schema validation. Skip it if Newtonsoft.Json already covers your needs and you are on an older .NET target, since these packages target .NET Standard 2.0 and .NET 8, 9 and 10. Before you add a package, check the specification list, because the project explicitly avoids duplicating work that another project already does well, and remember that the version of a schema draft is a real behavioural difference, since JsonSchema.Net supports drafts 6 and higher rather than the earliest drafts.

Frequently asked questions

Official sources

1. Issues
2. json-everything/json-everything on GitHub
3. License: MIT
4. Project website
5. README