Introducing Corvus.Text.Json V5: Schema Validation - 10× Faster

By Matthew Adams Co-Founder 10th June 2026 · 2 min read

At endjin, we maintain Corvus.JsonSchema, and in the previous post we saw how the source generator produces complete typed models from JSON Schema.

Now let's look at what happens when you call person.EvaluateSchema().

Validation is not optional

If you're working with JSON that crosses a trust boundary - API requests, message queues, configuration files, user-supplied data - you need to validate it. Not "check a couple of fields" validate. Schema validate. Against a specification that defines what valid means, and that both producer and consumer agree on.

JSON Schema is that specification, and it covers all the major drafts: 4, 6, 7, 2019-09, and 2020-12 - plus OpenAPI 3.0 and 3.1.

V5 validates over 10× faster than other .NET JSON Schema validators.

The generated validator

If you've followed the source generator approach from the previous post, validation is already built in:

using var doc = ParsedJsonDocument<Person>.Parse(
    """{"name":"Alice","age":30}""");
Person person = doc.RootElement;

bool valid = person.EvaluateSchema();  // true

That's it. The source generator produced a validation method tailored to your specific schema, with every keyword compiled into type-specific checks. There is no interpretation overhead and no runtime schema walking.

Getting diagnostic output

When validation fails and you need to know why, pass a results collector:

using var collector = JsonSchemaResultsCollector.Create(
    JsonSchemaResultsLevel.Detailed);

bool valid = person.EvaluateSchema(collector);

if (!valid)
{
    foreach (var result in collector.EnumerateResults())
    {
        if (!result.IsMatch)
        {
            Console.WriteLine(
                $"  Failed: {result.GetMessageText()} " +
                $"at {result.GetDocumentEvaluationLocationText()}");
        }
    }
}

When you call EvaluateSchema() without a collector, you get a simple pass/fail bool with maximum performance. If you need diagnostics, create a JsonSchemaResultsCollector and choose how much detail you want:

Use the no-collector overload in production hot paths; use Detailed or Verbose for diagnostics.

Dynamic validation at runtime

Not every scenario has schemas known at compile time. Schema registries, configuration validators, and user-supplied schemas all need runtime compilation.

The Corvus.Text.Json.Validator package handles this. Internally, it uses the same code generation engine as the source generator, but invokes Roslyn dynamically:

using Corvus.Text.Json.Validator;

// Load a schema - from a file, string, stream, or URI
JsonSchema schema = JsonSchema.FromFile("Schemas/person.json");

// Validate
bool valid = schema.Validate("""{"name": "Alice", "age": 30}""");

Compiled schemas are cached automatically by their canonical URI, so the first validation incurs a compilation cost (around 100ms) but subsequent calls are sub-millisecond.

Multiple input formats

The Validate() method accepts JSON in whatever format you already have it:

// UTF-8 bytes (zero copy from a network buffer)
bool valid = schema.Validate(utf8Bytes);

// Stream (HTTP request body, file stream)
bool valid = schema.Validate(stream);

// Pre-parsed element
using var doc = ParsedJsonDocument<JsonElement>.Parse(json);
bool valid = schema.Validate(in doc.RootElement);

Pre-loading referenced schemas

If your schema uses $ref to reference other schema files, you can pre-load them to avoid file system or network resolution:

var options = new JsonSchema.Options(
    additionalSchemaFiles: new[]
    {
        new AdditionalSchemaFile(
            "https://example.com/schemas/address.json",
            "Schemas/address.json")
    });

JsonSchema schema = JsonSchema.FromFile("person.json", options: options);

This is particularly useful in CI/CD environments where external resolution may be unreliable or disallowed.

Conformance

We take correctness seriously. The V5 engine passes the official JSON Schema Test Suite for all supported drafts, and we publish results to Bowtie - the cross-implementation conformance project.

Next up

We've seen validation from the caller's perspective. In the next post, we'll go deeper into the V5 memory model. We'll look at how ParsedJsonDocument<T> uses ArrayPool to achieve just 136 bytes per document.

FAQs